531–540 of 736 posts
Rust is great, but one thing I’d like to see is an interpreted, dynamic, less strict version of it that could be used for prototyping and gradually typed into compiling Rust code. In other words, a new programming language doing to Rust the reverse of what Mojo is trying to do to Python.
Earlier quoted context omitted.
I tried for a long time for chatgpt to help me write a simple function that generated a random array and then summed along the columns. Could not do it. Pasting in an error message, made chatgpt spit out another version of the code with some other error.
Go to ChatGPT and type "write a simple function that generated a random array and then summed along the columns". Run it. If there is an error, either debug it or ask ChatGPT to take a different approach. There's something wrong if you can't get it to do this.
Yes, there's something wrong here. But it isn't "not using chatgpt"...
Earlier quoted context omitted.
It feels like most of the hatred for rust async is for people that try to act like Tokio isn't async rust and that for some reason you should try to randomly avoid tokio for some reason.
Maybe because you want to keep the dependency tree under control and bringing in tokio suddenly adds fifty crates you never asked for. Every crate is a potential liability!
Adding it to your project probably increases the average code quality:)
Earlier quoted context omitted.
> and ubiquitous processes for easily mapping the URL to an alternative location. This seems strange to me because the whole point of a Uniform Resource Locator is to specify where a resource can be located. It's a bit like saying "My project depends on the binder on shelf 7 in Room 42, sixth binder from the left. Except when I go into production, then use...." Don't tell me what binder it's in, tell me what it is. I…
This was a big annoyance for me back in the day when I was dealing with XML namespaces. URLs never made sense for that use case and too many tools tried to pull XSDs from the literal URL which was always generally out of date, some projects switch to URIs like tag uris or URNs and it was much better, imo.
Earlier quoted context omitted.
80% of crates have no unsafe code in them.
I'm interested in what went into this number. I checked the six most recently published crates on crates.io (blablabla, nutp, tord, g2d, testpublishtesttest, hellochi, at the time of writing). Three of those (blablabla, testpublishtesttest, and hellochi) did some variation on printing `hello world`. g2d seems like an interesting graphics library. tord provides a data structure for transitive relations, which is also…
Also, you’re replying to someone who I’m fairly sure is on one of the core Rust teams, if not closely involved, I’m somewhat more inclined to trust _them_ when they say 80% of libs don’t contain unsafe (given that it cleanly meshes with my own experience of Rust libraries).
Earlier quoted context omitted.
C# is underrated by the HN crowd, I find. I quite like how mid sized firms (100-1000 employees) use it.
C# is a lovely language to work with. The only issue I have is with the .NET ... that is, building self-contained binaries to distribute. For comparison: * Hello World win-x64 binary self-contained in .NET 7 is around 70 MB * The same for Go results in 1.2 MB Edit: Missed 'trimming' in .NET, which would result in a binary of size around 11 MB in win-x64
And I was upset that they were so big. Sometimes I used UPX. Or I kicked out all Delphi GUI libraries, and created the GUI with the Win32 API calls directly. I got 50 KB Hello Worlds.
Earlier quoted context omitted.
> but the ergonomic is really bad. Every time I write some rust I feel limited. > But I do not think it is a good general purpose language. Remember that this is not a sentiment that's shared by everyone. I use Rust for tasks that need anything more complicated than a shell script. Even my window manager is controlled from a Rust program. I say this as someone who has been programming in Python for nearly two decades…
> At this point, I'm about as fast in Rust as I am in Python. This is factually impossible. For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages. This is not even considering more local complexities, like data structures with cyclical references.
I strongly agree from my own and my peers experience with the sentiment that latency from zero to running code is just higher in Rust than Python or Go. Obviously there are smart people around and they can compensate a lot with experience.
Earlier quoted context omitted.
I tried to get into rust for many years, I'm now in a C/CPP job (after Java/Python/Ruby and other gigs). What I've come to understand is that Rust's lifetime model is very difficult to work with whenever you have a cyclic reference. In C/CPP the same holds, but you deal with it through clever coding - or ignoring the problem and cleaning up memory later. Java, and other GC'd languages just work for these structures.…
> While the Rust devs believe such cyclic references are rare - They are. I have not had to use cyclic references ever, except once doing experiments with fully connected graphs, that was very unusual If you're doing a lot cyclic references Rust is not the right choice. Horses for courses But are you sure you're using the best algorithm?
Biggest turn off for me was Rust's horrendous syntax. Dangling apostrophes, wrapping the hell out of things, etc. Just look at this Result , Arc >. Absolutely horrendous.
Lifetimes need something to stand out as an identifier. 'a is weird, but works. Whether it could use a different ASCII sigil is a bikeshed problem.
Types borrowed from C++ to look less weird to C++ programmers. But this again is just a surface level issue. Semantically, the wrapper types are incredibly useful. Having all nested types spelled out is convenient when reading code – you know what you're getting and what are the standard properties of it.
Earlier quoted context omitted.
> At this point, I'm about as fast in Rust as I am in Python. This is factually impossible. For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages. This is not even considering more local complexities, like data structures with cyclical references.
> For anything larger than (very) small programs, Rust requires an upfront design stage, due to ownership, that it's not required when developing in GC'ed languages. It's nearly the opposite. For larger programs in Python, you need an upfront design stage because the lack of static typing will allow you to organically accrete classes whose job overlap but interfaces differ. Meanwhile, Rust will smack you over the hea…