211–220 of 294 posts
Earlier quoted context omitted.
I would like to add that async Rust still doesn't really work. That is a big negative for Rust.
This constant refrain must be discouraging to the people who have worked so hard on async rust. Can we please restrict our criticism to specific problems, and temper it with gratitude for the amazing things that the Rust developers have already given us free of charge?
Earlier quoted context omitted.
I would like to add that async Rust still doesn't really work. That is a big negative for Rust.
This constant refrain must be discouraging to the people who have worked so hard on async rust. Can we please restrict our criticism to specific problems, and temper it with gratitude for the amazing things that the Rust developers have already given us free of charge?
I’ve been using Rust as a hobbyist since 2015. I see what’s going on in the community, attend a meetup, and work on open source projects (mostly my own). I’m starting a side project, and after much consideration, I went with F# and AspNetCore. The maturity of the framework and solutions for web is hard to ignore. And then F# gives me a lot of what I like about Rust: union types, pattern matching, avoiding null… With…
Are you using ASP.Net Core straight up or through something like Giraffe? Also are you using JS or Fable/etc to handle the front end? The F# web ecosystem is something that I've done light research on but haven't done a real project with yet, but still incredibly curious about it.
For the front end, I have decided to do server-rendered pages, using Giraffe.ViewEngine. So the source for the HTML is all F# code too.
For interactivity and updates without a full page reload, I am using htmx. This has been so nice that I feel “done” with SPAs as the default choice for a web UI. 99% of the JS I need is encapsulated in a library. If I ever need more, I can just incrementally adopt Vue or something similar on a page that needs it and go from there.
Earlier quoted context omitted.
It's not that big issue https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
Both you and parent are correct. Memory safety issues in c++ code are common, but very often they don't manifest as segfaults. Malloc assertion failures or occasional data corruption in edge cases or "impossible" behavior are more typical symptoms.
Overall, the aversion to C++ and other non-GC languages is overly stated in the industry by vendors looking desperate for a problem to solve to validate using their new language or as a solution for companies that want to hire large armies of sub-par developers to bang on keyboards.
>(...) despite my experience and best intentions, I was in fact making mistakes with C. Subtle leaks, use-after-free,(...) Rust made it very clear that I was not the programmer I thought I was. This really resonated with me. I feel a lot more confident writing code in Rust than say in C or Java. However, in my opinion, it also comes with a downside: These days, whenever I use a 'more forgiving' programming language I…
I still find this type of comment odd (although I do also recognise that it's very common). I write a lot of code in C++. And I'm definitely no fan of it, so I'm not here to defend it! And I write a lot of bugs in that code. But very few of them are segfaults. With smart pointers and some common sense, they're just not that big of a concern. Yes, they do happen, but it's far a minority of the bugs. Maybe everyone jus…
I'm not sure what you mean by this exactly. Do you mean Rust would be a perfectly good language without its safety guarantees? Because it can't have them without lifetimes. It could instead have GC like Go/Java/etc, but now it's a GC language.
Lifetimes aren't a feature of the language. They are the implementation details for a couple features of the language. It's how it gets there. And I don't think Rust would have anywhere near the interest it has without those features.
Earlier quoted context omitted.
My experience (15+ years of debugging legacy C code) is that if the segfault is repeatable - as in you can make it happen in the same place over and over again - the fact that the error is somewhere else only makes things marginally more difficult. Even the old-fashioned debuggers can monitor memory locations for changes, and if that doesn't work you can set breakpoints in various locations and manually check memory…
In cases when I have a working visual debugger, I agree, it's fun. Without one, it's not fun.
Earlier quoted context omitted.
Do you pine for the nice days of C/C++, when men were men and spend hours on debugging segmentation faults?
Well, because geniuses who were too smart for their own good turned every problem into an academic exercise, writing "elegant" code using the darkest corners of the vast language that is C++. And then we hate the language and not these characters. Scala has the same problem. Stop writing your own DSLs!
100% disagree. Writing custom DSLs is how you get the best programs.
What does Rust offer over modern C++ with smart pointers and RAII?
- sane generics - better type system - better type inference (bidirectional) - better/standardized package manager - better error messages - memory safety - thread safety There are downsides but it’s an improvement on balance. I use both extensively.
> better type system
> better type inference (bidirectional)
how do you quantify "sane" and "better" here ?
Earlier quoted context omitted.
My experience (15+ years of debugging legacy C code) is that if the segfault is repeatable - as in you can make it happen in the same place over and over again - the fact that the error is somewhere else only makes things marginally more difficult. Even the old-fashioned debuggers can monitor memory locations for changes, and if that doesn't work you can set breakpoints in various locations and manually check memory…
In cases when I have a working visual debugger, I agree, it's fun. Without one, it's not fun.
Earlier quoted context omitted.
Rust doesn't have a mark-and-sweep GC. It has "automatic" memory management through static analysis. Rust's memory management is done by the compiler automagically inserting free() in the same places that you would put it manually in C.
I would add that it inserts free similarly to C++’s RAII, and it also have reference counting wrapper type which will free at runtime. Reference counting makes different tradeoffs to mark-and-sweet GCs, they usually have worse throughput, but better latency (when they are shared between threads, every new/lost reference does an atomic increment/decrement which is very expensive and happens on the working thread. Java…
It's not based on reference counting. It's possible to implement reference counting in user code (like C++ shared_ptr), but that is still notably different than languages that use reference counting as their primary memory management strategy (like Swift or CPython). In Rust reference count increases are manual, and refcounted values can be borrowed and safely passed around without updating the reference count.