141–150 of 736 posts
Earlier quoted context omitted.
[flagged]
This really is an inappropriate comparison. Can we be serious for a bit? A professional-grade tool providing professional-grade feedback is not remotely like an abusive or even turbulent relationship.
People do sick things with lifetimes and generic associated types. Sick, sick things.
> After two decades of JavaScript and decent experience with Go, this is the most significant source of frustration and friction with Rust. It’s not an insurmountable problem, but you must always be ready to deal with the async monster when it rears its head. In other languages, async is almost invisible. I am a former C and C++ programmer who lived calling into pthread almost every week for a decade. I use async rus…
The problem that I am running into at the moment is that a few things like the rhai Engine aren't Send and I am trying to use them in an async closure. What GPT-4 suggested was creating a tokio Runtime inside the thread and then block_on(). I will try it tomorrow. (This is the first significant Rust project for me.)
1. Fix rhai::Engine so it is Send (if !Send is unintentional)
2. Use tokio::spawn_blocking or normal threads to run the rhai::Engine bits
3. Don't hold the rhai::Engine across an await point.
Which one depends on rhai Engine details and what you want to accomplish.
Doing a block on inside a new thread seems unlikely to do anything useful (unless there's some undisclosed detail that makes it reasonable).
I encourage you to ask about this in the rhai repo in a discussion or issue.
Earlier quoted context omitted.
URLs for packages makes a lot of sense. It works well in the land of Go. It also conveniently eliminates the need for the language to have a global packages database. Upload your package to example.com/your-thing and it's released! (You can, of course, still offer a cache and search engine if you want to.)
No, URL's don't make sense because your application shouldn't care where on the internet your dependency happened to be hosted when you integrated it. It's location has nothing to do with what it is. By the time you're going to production, your vetted and locked dependency should be living in your own cache/mirror/vendored-repo/whatever so that you know exactly what code you built your project around and know exactly…
In the Go world this would be "vendored" dependencies, that is, the dependencies are within your source tree, and your CICD can build to its hearts content with no care in the world about the internet because it has the deps.
The URL is useful for determining which version of a specific project is being used - "Oh we switched to the one hosted on gitlab because the github one went stale"
The advantage of using gitlab, or github, or whatever public code repository is that you get to piggy back off their naming policies which ensure uniqueness.
But, at the same time, there's no reason that the repo being referred to cannot be in house (bob.local) or private.
Having said all of that, the Go module system is a massive improvement on what they did have originally (nothing) and the 3rd party attempts to solve the problem (dep, glide, and the prototype for modules, vgo), but it's not without its edge cases.
For typical applications I am learning nim, which has python syntax, c speed and size, and could be memory safe too.
I really feel nim deserves more love, for that you can balance coding-speed(write like python script), size , performance and security, and cal leverage c and c++ libraries without FFI, no other languages can have those at the same time.
Programming in Rust is really not like being in an abusive relationship. The compiler is trying to help out as much as possible, especially since rustc has the best error messages in the world.
[flagged]
If you want sugarcoating or simply rapid prototyping I'd use a dynamic or scripting language instead.
Earlier quoted context omitted.
Maven and Java really don’t get enough credit for how well it’s dependency management works. So many inferior dependency management systems for other languages have come along later, and learned nothing from those that came before it.
Is this a joke?
Earlier quoted context omitted.
A full 70% of security vulnerabilities are caused by memory safety issues. As professionals we need to get serious and have memory safety as a baseline requirement.
So we shouldn't use Rust at all, since Rust is not completely memory safe since it let's you disable the borrow checker. We should be serious as professionals and use safe languages like Java, JS, Python, etc. But of course there are use cases where you need memory safety guarantees and bare metal performance. In those cases, sacrificing some memory safety by using Rust is an acceptable tradeoff I think.
No, it doesn't. What's interesting isn't so much that random HN posters believe this sort of thing, because hey, who needs to know anything about a topic to post their opinion on a forum right? No, what's fascinating is that this applies to people like Herb Sutter in his "cpp2" language, here's Herb:
> I don’t like monolithic "unsafe" that turns off checking for all rules
Nobody does that. It's possible Herb knows that and is being deceitful but honestly I think it's more likely that without investigating at all Herb has just decided everybody else is an idiot...
Perhaps my biggest critique is that crates.io has no namespacing. Anyone can just claim a global and generic package name and we mostly have to deal with it (unless you avoid using the crates.io repository, but then you'll probably have more problems...). Some of these globally-claimed generic packages are not really the best package to use. Maybe it was a reaction against the Java-style reverse DNS notation, which i…
It's definitely a good thing that people choose new unique names for crates rather than dijan/base64 vs dljan/base64
Do understand the desire of having a crate for audio manipulation called "audio" but at the same time how often do we end up with "audio2" anyway? It's an imperfect solution for an imperfect world and I personally think the crates team got it right on this one.