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

Why is Rust difficult?

vorner.github.io

Post reply on HN
Print view View original

71–80 of 260 posts

Re: Why is Rust difficult?

#71

Post by pjmlp »

Rusky wrote: post #68
pjmlp wrote: post #51

Earlier quoted context omitted.

Try to use the borrow checker of this decade to write callbacks in GUI frameworks, without polluting the code with Rc and RefCell, even though it is obvious there is only one path to the data being used.

Callbacks by definition create multiple paths to the data. (You can also often get away with Cell rather than RefCell.)

> Callbacks by definition create multiple paths to the data.

How come, when you have a struct method, accessing field members only visible to that specific method.

Something that is very easy to do with moving in lambda contexts in C++.

Re: Why is Rust difficult?

#72

Post by carlmr »

bonesss wrote: post #60
cortesoft wrote: post #5

I do think a lot of the difficulty when starting Rust was all about it forcing you to do everything correctly, even when the 'correctness' wasn't needed for how the program was currently being used. However, my experience learning Rust was that it was pretty easy to work through these things because of how precise the compiler is at describing the issue. I feel like the compiler was my teacher, and it kept on teachin…

> I feel like the compiler was my teacher, and it kept on teaching me new concepts to look up in the docs. I work primarily in F#, a functional .Net language, which also enforces strict rules at compile time to ensure correctness... With the benefit of experience it's amazing and comforting and lets you reason happily about applications at a higher level. It's on of my favorite parts of the language, TBH. And while I…

I went to F# from C#, but I felt the transition was easier than going from C to Rust. I kind of noticed that I used some functional concepts a lot in my C# anyway. I always liked side-effect free functions, I tended to do a lot with LINQ transformations already, etc. F# made a lot of these things nicer to use (+ pattern matching + discriminated unions +++)

Re: Why is Rust difficult?

#73

Post by adwn »

pjmlp wrote: post #67
adwn wrote: post #62

Earlier quoted context omitted.

> I think that we could find ways to make equally memory-safe languages that go about enforcing safety in entirely different manners than with ownership and lifetime semantics. Of course, but at the cost of requiring a garbage collector. Mandatory GC has three main drawbacks: * It makes it harder and much less convenient to call libraries in this language from other languages. * Low-resource embedded systems are a no…

> Low-resource embedded systems are a no-go. Only if talking about microcontrolers with few hundred KB, where even C is a challenge. There are Java and Oberon implementations for single digit MB, like Cortex-M4.

> There are Java and Oberon implementations for single digit MB, like Cortex-M4.

So? Just because you can use a language on a given system doesn't mean that you should use it in any serious context.

A GC typically makes memory usage and execution latency non-deterministic, or at the least very hard to analyze. If your washing machine software OOMs whenever the GC didn't run between two button pushes, you'll have a great Heisenbug.

Re: Why is Rust difficult?

#74

Post by EugeneOZ »

jadbox wrote: post #31

I feel Go and Rust are great options for writing modern server side applications today, but they exist on two different ends of the spectrum. The Go language is highly minimal, constrained, and forces devopers to write unified code, that performs extremely fast idiomatically. This uniformity is helpful for open source collaboration. Rust is a much more robust language (eg generics), but is more complicated to pick up…

Rust is simple enough for web app needs. It took me about 4 months to start writing code in JavaScript not worse than open source libraries. It took the same time to learn Rust and start writing code, clean and dry enough, with almost 100% tests coverage.

Rust gives something Go can't: when you receive warning "variable doesn't need to be mutable", and you know you make it mutable intentionally, you know you just caught huge error (made by human, not compiler).

It's just one example, in general I feel compiler is my best friend, always 100% honest to me.

Re: Why is Rust difficult?

#75

Post by blattimwind »

pjmlp wrote: post #67
adwn wrote: post #62

Earlier quoted context omitted.

> I think that we could find ways to make equally memory-safe languages that go about enforcing safety in entirely different manners than with ownership and lifetime semantics. Of course, but at the cost of requiring a garbage collector. Mandatory GC has three main drawbacks: * It makes it harder and much less convenient to call libraries in this language from other languages. * Low-resource embedded systems are a no…

> Low-resource embedded systems are a no-go. Only if talking about microcontrolers with few hundred KB, where even C is a challenge. There are Java and Oberon implementations for single digit MB, like Cortex-M4.

> Only if talking about microcontrolers with few hundred KB, where even C is a challenge.

C is the default and not a challenge on 8-bitters.

Re: Why is Rust difficult?

#76

Post by josephg »

jchw wrote: post #37

I like Rust so far, but there's a few things I think aren't true: * That Rust is only harder because it enforces 'correctness.' It certainly is harder because it enforces correctness, but it's also harder because of how . I'm not saying there's a better approach to this, but I think a lot of people are implying that there isn't, and I don't think that's a safe assumption. I think that we could find ways to make equal…

> Go is another programming language I like, ... Fearless concurrency is a wonderful feature, but for embarrassingly parallel problems Go works wonderfully.

I adore Go's concurrency model but loathe go's actual language. The constant repetition in error handling, lack of generics and lack of parameterised types and Option make it feel like a children's toy set version of C instead of a useful modern language akin to Rust and Swift (and modern javascript).

I really really love the concurrency model though. And as far as I can tell there isn't much like it available elsewhere. You can make a similar concurrency model in rust, but you have to use much heavier OS level threads to do it, and all the other crates don't support it. Erlang / elixir do it but come with a much higher runtime performance penalty. Pony is interesting but very new - there aren't a lot of libraries for it and when I was playing with it the compiler seemed crazy slow.

I'm a little bit tempted to make a simple compile-to-go language. I'd get lynched at Go meetups for fragmenting the ecosystem, but it might be worth it. I like almost everything about go except the language itself.

Re: Why is Rust difficult?

#77

Post by jononor »

TheDong wrote: post #57
jacobush wrote: post #48

Earlier quoted context omitted.

Made me think, maybe they should check if you are using IEEE 754 correctly...

Numeric 'correctness' is a business-problem property. For a game engine, correctness is speed and "right enough". For a research physics simulation, it may be "as right as possible". You can't check whether floating point inaccuracy is correct generically because the definition is entirely dependent on the business needs of the program in question.

One could enforce the strictest correctness by default, and then allow/require to opt-out in cases where programmer decides it is OK, like a game.

Re: Why is Rust difficult?

#78

Post by pjmlp »

blattimwind wrote: post #75
pjmlp wrote: post #67

Earlier quoted context omitted.

> Low-resource embedded systems are a no-go. Only if talking about microcontrolers with few hundred KB, where even C is a challenge. There are Java and Oberon implementations for single digit MB, like Cortex-M4.

> Only if talking about microcontrolers with few hundred KB, where even C is a challenge. C is the default and not a challenge on 8-bitters.

So which compiler does offer 100% ANSI C compliance on something like a Z80 or PIC?

Re: Why is Rust difficult?

#79

Post by pjmlp »

adwn wrote: post #73
pjmlp wrote: post #67

Earlier quoted context omitted.

> Low-resource embedded systems are a no-go. Only if talking about microcontrolers with few hundred KB, where even C is a challenge. There are Java and Oberon implementations for single digit MB, like Cortex-M4.

> There are Java and Oberon implementations for single digit MB, like Cortex-M4. So? Just because you can use a language on a given system doesn't mean that you should use it in any serious context. A GC typically makes memory usage and execution latency non-deterministic, or at the least very hard to analyze. If your washing machine software OOMs whenever the GC didn't run between two button pushes, you'll have a gr…

Well, I happen to consider factory control management, weapon targeting and missile tracking systems, some big serious context.

Here is just one of them.

http://www.militaryaerospace.com/articles/2006/10/lockheed-m...

"PERC Ultra offered Lockheed Martin the responsiveness it needed to meet its most demanding timing requirements. In addition to real-time threading and deterministic garbage collection, PERC Ultra provided the instrumentation and VM management tools necessary to support the mission-critical real-time requirements of the Aegis Weapon System."

"The Lockheed Martin-developed Aegis Weapon System is the sea-based element of the U.S. Ballistic Missile Defense System. The Aegis Weapon System is a radar and missile system integrated with its own command and control system, capable of simultaneous operation defending against advanced air, surface, and subsurface threats."

Is that serious enough for you?

Re: Why is Rust difficult?

#80

Post by turbinerneiter »

StudentStuff wrote: post #70
pjmlp wrote: post #67

Earlier quoted context omitted.

> Low-resource embedded systems are a no-go. Only if talking about microcontrolers with few hundred KB, where even C is a challenge. There are Java and Oberon implementations for single digit MB, like Cortex-M4.

Even the ESP8266, where ram & flash are measured in kilobytes can run a minimal version of python. This whole "low resource can't run heavy languages" trope needs to die.

Comparison of a sensor fusion algorithm the likes of which are used in quadcopters:

| impl | c | py3 | mpy | pypy3 | cy3 |

|------|-------|--------|---------|-------|-------|

| [ns] | 0.176 | 11.462 | 37.633 | 0.818 | 0.590 |

| .c | 1.000 | 65.126 | 213.824 | 4.648 | 3.352 |

mpy - MicroPython

cy3 - Cython

So, ... low resource can't run heavy languages fast (yet?). Good thing is by using MicroPython and writing the time critical stuff in C you can get the best of both worlds while paying the least.

edit: sigh, markdown table

Post reply on HN