611–620 of 811 posts
Earlier quoted context omitted.
What language actually makes it simple?
This is very commonly done in C++. My programs do a flurry of mmap s in the first second, then run for, sometimes, years without allocating again.
Earlier quoted context omitted.
IMHO it would be good for Rust to become popular niche/specialist language for systems programming. Currently Rust is not as complete or well defined as Ada/SPARK or MISRA C/C++ combined with commercial analyzers (Astree for example). At the same time Rust is "too sound and rigorous" for mainstream programmers. Rust advocates are in the losing battle of of forcing mainstream to adopt "it does not compile unless compu…
I for one as someone who programmed professionally in both Ocaml and Ada still don’t see where Rust is supposed to fit. If I was doing something high level, I would probably use Ocaml which has nicer features. If I wanted to write safe code, Ada offers a better experience with the availability of SPARK for parts I would probably end up wanting to prove. If I just want to write concurrent code with the certainty I cou…
Earlier quoted context omitted.
Unpopular opinion but the whole memory safe idea is more niche than HN commenters would have us believe. Most of us are writing web apps and services that do not have strict memory requirements nor catastrophic failure modes. Dynamic languages and GC'd languages cover most of what our employers are paying us for: web apps, backend services. It is ironic to build super safe software, then deploying them on kubernetes,…
There seems to be a myth that Rust is unusual in being memory safe. All modern GCed languages are memory safe (assuming you don't do anything obviously unsafe like manipulate raw pointers, which some languages might let you do if you really want to). >It is ironic to build super safe software, then deploying them on kubernetes, written in a GC'd language prone to nil dereference errors. Nil dereference errors don't d…
I don't think the null handling in rust is about memory safety so much as it is their choice in error handling. If you come across a null pointer dereference and your code doesn't handle it, that's a hidden bug. Triggering an exception and handling it is a valid approach, but there are trade-offs. If no code handles the nil exception for example then it's no better than crashing as you would in C. Wrapping things up in try catch can lead to missing recoverable errors or unexpected states. The choice to disallow null is one to avoid common bugs, not one for memory safety, as far as I understand it.
I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership an…
It puts the reference counting in the type system. Like the default string type and arrays (=vectors) are reference counted. And for speed you could use manual memory management
Any string literal is like an arc. E.g. in Delphi you can now write string concatenation like:
var a = 'bcd';
var b = 'xyz';
var c = a + b;
let a = Arc::new(String::from("bcd"));
let b = Arc::new(String::from("xyz"));
let c = format!("{}{}", a,b)Earlier quoted context omitted.
This comment right here. For most people who program for a living, the hype over Rust means little. They need to use what is in the industry right now. Often, that is a tried and true language that is relatively easy to learn and use. Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast.
> Having a complex programming language which limits you and controls how you use it does not sound appealing to those who need a feature done, fast. This sounds as insane to me as a carpenter who works with power tools saying. "Having safety measures which limits you and controls how you you have to do certain things does not sound appealing to those who need a house build, fast."
I see a lot of people here saying something like "Just use Arc , it will be plenty fast". As someone who does it all the time, I noticed that code becomes less readable and hard to comprehend that way. Important types stand much less out in function signatures once you have Arc >. Rust is already extremely verbose and adding additional layers to types doesn't help. Not even to mention that now every time you want to…
Rust pro tip: use type alias. As for using lock() - you'd have to do it in any language in some way. If you have sharing and mutability, you need some kind of synchronization.
Earlier quoted context omitted.
> Much of what is routinely used to capture semantics into mainstream C++ libraries is wholly impossible to express in Rust. (C is not even a participant, here.) This is not about template metaprogramming, just ordinary stuff. Do you have any examples?
All above languages are turning complete, so if you can express it in one you can express it in another. The question isn't can you write it, the question is how hard is it to do, and how performant the code will be. The heart of C++ is destructors: a bit of code that you can write and the compiler will ensure runs when code goes out of scope/is deleted. You can do this in C by remembering to manually call the right…
Rust doesn't have class inheritance, no, but often combining traits and delegating to a "parent" field works. Although sometimes that can be considerably more cumbersome, yeah.
Earlier quoted context omitted.
I made the mistake of trying to learn Rust while doing async programming. IMO, when it comes to concurrent, it's a matter of picking your poison: Threaded Rust: No overhead of a GC, but overhead of context switches and multiple stacks. NodeJS: No overhead of context switches and multiple stacks, but the overhead of a highly optimized GC. (And I suspect that the GC can do tricks like run when the process is waiting on…
There’s plenty of real world data. I forget the name of the website but web server benchmarks are pretty good at showing the differences.
Earlier quoted context omitted.
Rust pro tip: use type alias. As for using lock() - you'd have to do it in any language in some way. If you have sharing and mutability, you need some kind of synchronization.
Only in Rust you need synchronization when accessing an object from multiple places on the same thread .
Earlier quoted context omitted.
If your primary criticism of golang is that its creator doesn't like syntax highlighting, then it must be doing pretty good.
It is mostly an example of the mindset that I think GP is trying to illustrate. Go has nil where Rust has Option. Go has weird not-quite-tuple returns & if err != nil where Rust has Result. Go has no real enum concept, where rust has its powerful enums and matching constructs. Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system). I lik…
Viewed through this lens, the resistance on the part of the creators to changes that compromise these values even a little bit makes sense. Generics take time to get used to and any code base that makes extensive use of them will take longer to get up to speed in, even if it enables you to move faster later on.
That talk has really shaped how I look at Go. I think it solves problems that Google has (really large projects built by teams that have a ton of turnover) really well. But as with a lot of things that emerge from Google, it’s a solution to a problem that not too many other companies face. The ones that do will get an awesome tool that’s proven to work. But the ones for whom it’s 90% of what they need are going to get a lot of pushback getting that last 10% accepted because it already does almost exactly what Google needs it to do and any departure from that will be, in their minds, counterproductive.