Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating away from Rust

deadmoney.gg

Post reply on HN
Print view View original

711–720 of 799 posts

Re: Migrating away from Rust

#711

Post by neonsunset »

Groxx wrote: post #706
bmitc wrote: post #213

Earlier quoted context omitted.

I find it interesting how the software industry has done everything it can to ignore F#. This is me just lamenting how I always come back to it as the best general purpose language.

To within a rounding error of zero, I don't think anyone outside Windows devs truly expects Microsoft to maintain .NET on other platforms, so it's not really an option in many (most?) fields. They've effectively dropped it a couple times in the past, and while they're currently putting effort in, the company as a whole does not seem to care about stuff like this beyond brief bursts of attention to try to win back dev…

> To within a rounding error of zero, I don't think anyone outside Windows devs truly expects Microsoft to maintain .NET on other platforms, so it's not really an option in many (most?) fields.

This is provably wrong, unless you want to insist despite the facts because that's what your social bubble tells you to do.

The most popular deployment target for .NET is Linux: https://dotnet.microsoft.com/en-us/platform/telemetry

Equating whatever else MS is up to with the way .NET evolves and is managed is no different to equating YouTube and Golang.

Re: Migrating away from Rust

#712

Post by fooker »

pornel wrote: post #413
fooker wrote: post #48

Earlier quoted context omitted.

Memory is sometimes faster today!

In absolute terms yes, but relative to the CPU speed memory is ridiculously slow. Quake struggled with the number of objects even in its days. What you've got in the game was already close to the maximum it could handle. Explosions spawning giblets could make it slow down to a crawl, and hit limits of the client server protocol. The hardware got faster, but users' expectations have increased too. Quake 1 updated the…

> relative to the CPU speed memory is ridiculously slow

Latency from cpu to memory sure.

Memory frequency has caught up though, so you have have more bandwidth than any CPU can deal with.

Re: Migrating away from Rust

#713

Post by scott_w »

Ygg2 wrote: post #602
scott_w wrote: post #545

Earlier quoted context omitted.

> Maybe you had the luck of learning 0 based language first. Then most of them were a smooth ride. Given most languages since at least C have 0-based indexing... I would think most engineers picked it up early? I recall reading The C Programming Language 20 years ago, reading the reason and just following what it says. I don't think it's as complex as the descriptions people put forward of "fighting the borrow checke…

> Given most languages since at least C have 0-based indexing. As I mentioned I started Basic on C64, and schools curriculum was in Pascal. I didn't learn about C until I got to college. > One is "mentally add/subtract 1" and another is "gain a deep understanding of how memory management works in Rust." In practice they are, you start writing code. At first you trip on your feet, read stuff carefully, then try again…

I literally just described my process, so I don’t get how you got to “you don’t know how you know” because… well… I just told you.

Also, there’s a huge difference between beginners not understanding 0-based indexing and experienced C++ engineers describing the challenges understanding Rust’s unique features. I mean, Jesus Christ, we’re commenting on a thread here of experienced engineers commenting on how challenging it can be! I really don’t know what else to say.

Re: Migrating away from Rust

#714

Post by klabb3 »

jfndbdbdb wrote: post #688
frontfor wrote: post #455

Earlier quoted context omitted.

Agreed. For the same reason I unironically prefer Java, Go, C++, JS/TS to solve real problems.

I see Java, Go and C++ but js/TS is even worse than rust with regards to package deprecation

My main gripe with npm is the massive complexity of packaging when you have transpilation and different modes in the package.json file. Especially with component libs that need to be packaged.

Re: Migrating away from Rust

#715

Post by weird_trousers »

klabb3 wrote: post #204

The fact that people love the language is an unexpected downside. In my experience the rust ecosystem has an insanely high churn rate. Crates are often abandoned seemingly for no reason, often before even hitting 1.0. My theory is this is because people want to use rust primarily, the domain problem is just a challenge, like a level in a game. Once all the fun parts are solved, they leave it for dead. Conversely and…

> Crates are often abandoned seemingly for no reason, often before even hitting 1.0.

That is the one of the first things my colleagues told me after trying Rust for a few weeks: a laaaarge number of crates under 1.0, and so many abandoned crates, still published in crates.io. Some of those have even reported CVEs due to heavy `unsafe` usage for... nothing.

I love Rust, but I have the feeling that the language (and its community) lost the point since the release of the 2018 edition.

Re: Migrating away from Rust

#716

Post by bigfatfrock »

harles wrote: post #284
janalsncm wrote: post #280

Earlier quoted context omitted.

> These crates also get "refactored" every few months, with breaking API changes I am dealing with similar issues in npm now, as someone who is touching Node dev again. The number of deprecations drives me nuts. Seems like I’m on a treadmill of updating APIs just to have the same functionality as before.

I’ve found such changes can actually be a draw at first. “Hey look, progress and activity!”. Doubly so as a primarily C++ dev frustrated with legacy choices in stl. But as you and others point out, living with these changes is a huge pain.

If only middle management and project managers the world over had such a positive perspective!

Re: Migrating away from Rust

#717

Post by adamnemecek »

hu3 wrote: post #98
adamnemecek wrote: post #85

For anyone considering Rust for gamedev check out the Fyrox engine https://fyrox.rs/ here's a web demo https://fyrox.rs/assets/demo/animation/index.html

Sorry but this engine had(s) problems rendenring a simple rectangle with alpha channel texture, not longer than 3 months ago (I'm assuming it was fixed). Is it normal for Rust ecosystem to suggest software with this level of maturity? https://github.com/FyroxEngine/Fyrox/discussions/725

> Is it normal for Rust ecosystem to suggest software with this level of maturity?

Yeah, all Rust programmers are obligated by a blood pact to do this.

Re: Migrating away from Rust

#718

Post by int_19h »

WalterBright wrote: post #476
Ygg2 wrote: post #439

Earlier quoted context omitted.

Yes but why does no one talk here about fighting the 0 indices. Or how they are switching to Lua, because 0 indices are hard? Am I the only person that remembers how hard it was to wrap your head around numbers starting at 0, rather than 1?

> 0 indices are hard? I started out with BASIC and Fortran, which use 1 based indices. Going to C was a small bump in the road getting used to that, and then it's Fortran which is the oddball.

Most oldschool BASIC dialects (including the original Dartmouth IIRC) use 0-based indices, though. It's the worst of both worlds, where something like:

  DIM a(10)
actually declares an array of 11 elements, with indices from 0 to 10 inclusive.

I believe it was QBASIC that first borrowed the ability to define ranges explicitly from Pascal, so that we could do:

  DIM a(1 TO 10)
etc to avoid the "zero element tax"

Re: Migrating away from Rust

#719

Post by int_19h »

bunderbunder wrote: post #122
ChadNauseam wrote: post #106

Earlier quoted context omitted.

This is getting downvoted but it's kind of true. Indexing collections all the time usually means you're not using iterators enough. (Although iterators become very annoying for fallible code that you want to return a Result, so sometimes it's cleaner not to use them.) However this problem does still come up in iterator contexts. For example Iterator::take takes a usize.

An iterator works if you're sequentially visiting every item in the collection, in the order they're stored. It's terrible if you need random access, though. Concrete example: pulling a single item out of a zip file, which supports random access, is O(1). Pulling a single item out of a *.tar.gz file, which can only be accessed by iterating it, is O(N).

In C++, random access iterators are a thing. Indeed, raw pointers satisfy the requirements of a random access iterator concept. Is that not the case in Rust?

Re: Migrating away from Rust

#720

Post by int_19h »

virtualritz wrote: post #536

It sounds to me that it may have been better to limit performance-critical parts to Rust and write the actual game in something like Lua (embedded in Rust)? That's the approach I've been taking with a side project game for the very reason alone that the other contributors are not system programmers. I.e. a similar situation as the author had with his brother. Rust was simply not an option -- or I would be the only on…

But why, when you can write performance-critical parts in low-level C# (with structs, stackalloc etc) and game logic in high-level object-oriented C#, and have seamless interop between the two with no effort at all?
Post reply on HN