471–480 of 546 posts
My experience is that languages survives not because of a particular feature, but because they are USEFUL in practice to produce a software. The fact that C is used in so many places speaks for itself about it usefulness. And this is done by writing software by majority of C programmers instead of jumping on every forum to attack other languages, writing extended blog posts just to convince people that they "should"…
Earlier quoted context omitted.
> Okay, but if I do this everywhere, then I de facto don't have memory safety. No, that's not how this works. You write the unsafe code in one place and make sure it's correct (just like you'd do in C or Jai), and then you wrap it in a function signature that lets the compiler apply its memory safety checks to all the places that call it (this is what Rust gives you over C). This is still a meaningful improvement to…
> that lets the compiler apply its memory safety checks to all the places that call it My point is that those memory safety checks are now meaningless. > This is still a meaningful improvement to memory safety over C. No, it really isn't. What you are describing is almost exactly what you get in C.
Earlier quoted context omitted.
No it's not. Its regex library is written in Rust, but was inspired by RE2. It shares no code with RE2. (And RE2 is a C++ library, not C.) Off the top of my head, the only C code in ripgrep is optional integration with PCRE2. In addition to whatever libc is being used on POSIX platforms. Everything else is pure Rust.
It couldn't figure it out from looking through ripgrep's website: does ripgrep support intersection and complement of expressions? Like eg https://github.com/google/redgrep does. Regular languages are closed under those operations after all.
Paul's talk introduced redgrep is amazing by the way. Give it a watch if you haven't yet: https://www.youtube.com/watch?v=Ukqb6nMjFyk
ripgrep's regex syntax is the same as Rust's regex crate: https://docs.rs/regex/1.4.4/regex/#syntax (Which is in turn similar to RE2, although it supports a bit more niceties.)
Earlier quoted context omitted.
The interesting thing here is that rust has good threading and fantastic crates I played with making a regex library in rust. Which, as per RE2 design involves constructing graphs and glueing them together as the regex is traversed This requires a cycle catching gc, or, just a preallocated arena... It was my first foray into rust and felt I would need to be hitting into unsafe, which I wasn't ready for. Array indexin…
> I played with making a regex library in rust. Which, as per RE2 design involves constructing graphs and glueing them together as the regex is traversed You could instead go with a derivatives approach. https://en.wikipedia.org/wiki/Brzozowski_derivative
Earlier quoted context omitted.
>> One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. How did you do that in Rust? Doesnt one of those have to own the scene at a time? Or is there a way to make that exclusive ownership more granular?
Since this got so many upvotes, I'll say a bit more. I'm writing a viewer for a virtual world. Think of this as a general-purpose MMO game client. It has no built-in game assets. Those are downloaded as needed. It's a big world, so as you move through the world, more assets are constantly being downloaded and faraway objects are being removed. The existing viewers are mostly single thread, in C++, and they run out of…
Earlier quoted context omitted.
> Okay, but if I do this everywhere, then I de facto don't have memory safety. No, that's not how this works. You write the unsafe code in one place and make sure it's correct (just like you'd do in C or Jai), and then you wrap it in a function signature that lets the compiler apply its memory safety checks to all the places that call it (this is what Rust gives you over C). This is still a meaningful improvement to…
> that lets the compiler apply its memory safety checks to all the places that call it My point is that those memory safety checks are now meaningless. > This is still a meaningful improvement to memory safety over C. No, it really isn't. What you are describing is almost exactly what you get in C.
Please take some time and think about this a bit more. Please think about how code review processes work, how audits work, how human attention spans work. Please think about how people endlessly nitpick small PRs but accept large ones with few comments. What unsafe does is make it easy to spot the small bits of critical code to nitpick while not having to worry about safety for the rest.
You're better than this, Jon.
Earlier quoted context omitted.
I mostly agree with your post but: > If you need a data structure more complex than an array of something, C is stupidly verbose. What’s stupidly verbose about Structs to you?
"Data structure" here probably means something like a linked list, binary tree, or hash table.
Earlier quoted context omitted.
Yes. But it’s not just taking care of those things that must be done; it seems to bloat the code. I think it’s a great alternative to C for large apps like Firefox, and perhaps it’s a good alternative to Go for services. For general purpose, I personally want something fast that’s easy, clear, and concise like Ruby. Do I just accept that Rust is the most evolved version of C, or is my gut correct that it’s bloated? I…
Ruby is not fast.
Earlier quoted context omitted.
> here you imply they would be used internally to data structures, in a way that doesn't reach out to user-level. Ah! I think I am understanding you a bit better. The thing is, ultimately, Rust is as flexible as you want it to be, and so there are a variety of options. This can make it tricky, when folks are talking about slightly different things, in slightly different contexts. When you say "doesn't reach out to us…
> rather than sweeping, incorrect statements that lead people to believe things that aren't true I agree, and if I say things that are incorrect, then I definitely want to fix them, because I value being correct. But what I am meeting in this thread is people wanting to do some language-lawyer version of trying to prove I am incorrect, without addressing the substance of what I am actually saying. I think your replie…
I do think this is probably true, and I know you do care about this! The thing is...
> The code that I write just looks way different from the code you guys write, the things I think about are way different, etc.
This is also probably true! The issue comes when you start describing how Rust code must be or work. There's nothing bad about having different ways of doing things! It's just that when you say things like "since then you are putting unsafe everywhere in the program," when that's empirically not what happens in Rust code.
> Using a bump allocator in the way you just did, on the stack for local code that uses the bump allocator right there, is semantically correct, but not a very useful usage pattern.
Yes. I thought going to the simplest possible thing would be best to illustrate the concept, but you're absolutely right that there is a rich wealth of options here.
Rust handles all four of these cases, in fairly straightforward ways. I also agree that 3 isn't often talked about as much as it should be in the broader programming world. I also have had this hunch that 3 and 4 are connected, given that the stack sometimes feels like an arena for just the function and its children in the call graph, and that it has some connection to the young generation in garbage collectors as well, but this is pretty offtopic so I'll leave it at that :)
Rust doesn't care just about 4 though! Lifetimes handle 3 as well; they ensure that the pointers don't last longer than the arena lives. That's it.
I don't have time to dig into this more, but I do appreciate you elaborating a bit here. It is very helpful to get closer to understanding what it is you're talking about, exactly. I think I see this differently than you, but I don't have a good quick handle on explaining exactly why. Some food for thought though. Thanks.
(Oh, and it is the one you're thinking of; I forgot that you had commented on that. My point was not to argue that the specifics were good, or that your response was good or bad, just that different strategies for handling memory isn't unusual in Rust world.)
Earlier quoted context omitted.
"Data structure" here probably means something like a linked list, binary tree, or hash table.
Linked list, binary tree, and heck, even a hash table aren’t “stupidly verbose” to me in C either, hence my question to GP.
Every one of those things requires a fairly primitive function call that sometimes doesn't even need to exist in another language. For contrast, think about all the macrology that the Linux kernel does to iterate across every element of a linked list that is effectively "for element in list {}" in any higher language.
And, even worse, most of that stuff in C needs to be runtime-only, while some of this kind of thing gets elided by the compiler in other languages.
If you don't consider all that "stupidly verbose" I'm really curious what you would?
And this is long before we start talking about concurrency.
C allows you to write something that works "just enough" that you put it into production and then it bites you in the ass (similar to quadratic algorithms--functional enough to get to production and then bite you).