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

111–120 of 260 posts

Re: Why is Rust difficult?

#111

Post by eptcyka »

Animats wrote: post #50

Rust's problem is not correctness. The borrow checker is the good part of the language. It's feeping creaturism. The language started out as imperative, and then became semi-functional. It started out as thread-oriented, and now is acquiring "green threads"/coroutines/cooperative multitasking. The generics system and library started where C++ and Boost left off. The "trait" system was more "objects bad, must do somet…

It's not getting green threads per se, it's getting co-routines. Even then, the co-routines will be mostly a library feature rather than a language feature. As for the distinction between coroutines and green threads - coroutines explicitly yield whilst green threads can be pre-empted. Implementing coroutines without a runtime is hard, implementing green threads without a runtime is harder.

Re: Why is Rust difficult?

#112

Post by vlovich123 »

coldtea wrote: post #92
vlovich123 wrote: post #82

Earlier quoted context omitted.

You make some good points but I think it's incorrect to compare Rust & Go. Rust is a systems programming language. It competes with C/C++ more than other high-level languages. In fact, while Go was originally positioned as a systems language but it ended up attracting people from scripting languages like Python because its performance characteristics put it there. You'd probably never bother building a serious web br…

> In terms of correctness, I've never heard claims about improving security issues, except in so far as those caused by memory/concurrency - think of it as necessary but not sufficient for security. Huh? Those might not be sufficient, but are the source of 99% of security issues.

Spectre & meltdown would like to have a word with you. Yes, memory/concurrency are a large class of problems for C/C++, but plenty of security issues still exist in other languages (check out the CVE count for Django for instance). The thing about security is that attackers will predominantly use the path of least resistance. As prevention evolves so does the sophistication & vector of attacks (e.g. timing attacks attack high-level implementation details rather than buffer overflows or algorithmic flaws). Do you have any supporting evidence for your 99% claim? That seems vastly overstated.

Re: Why is Rust difficult?

#113

Post by vardump »

pjmlp wrote: post #88
flohofwoe wrote: post #84

Earlier quoted context omitted.

SDCC is standard compliant (even up to C11) and has support for Z80: http://sdcc.sourceforge.net/

Thanks for pointing it out, I wasn't aware of it and it does look good, but they clearly state the uses cases which it isn't fully ANSI C compliant on page 24 of the documentation.

I think you're nitpicking.

That's close enough in my book. Those MCUs are tricky targets and I can certainly live for example with not being able to pass structs as return values. Or without re-entrancy. Perfectly understandable once you take into account limited IRAM space, 128 or 256 bytes, where stack, register banks and most of your temporaries and globals need to reside.

Re: Why is Rust difficult?

#114

Post by jules »

adwn wrote: post #62
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…

> 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…

Why does GC make it harder to call libraries in other languages?

Re: Why is Rust difficult?

#115

Post by matthewmacleod »

josephg wrote: post #76
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…

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.

I would love this; I feel entirely the same. The runtime is pretty good, performance is nice, concurrency is great, the tooling is wonderful (if you ignore the GOPATH nonsense and thew lacklustre package management solution). The language itself is quite frustrating to use, full of needless repetitive boilerplate and a mediocre type system.

I'd love a similar language with all the goodies that I find make development safer and more productive: proper enums, pattern matching, sum types, generics, and a handful of other features.

Re: Why is Rust difficult?

#116

Post by vardump »

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…

> A GC typically makes memory usage and execution latency non-deterministic, or at the least very hard to analyze.

You could say same about malloc and free. Not deterministic at all either. Memory fragmentation is a huge issue as well, and can bring down the whole system.

Typical GC (not all flavors) has a huge advantage on microcontrollers: you gain ability to compact heap. No more fragmentation.

That said, mostly I try not to dynamically allocate anything in firmware or kernel drivers. Whenever possible. Sometimes I write my own specialized allocators. For example a simple wait free allocator fast and rugged enough to call from an interrupt service routine.

Re: Why is Rust difficult?

#117

Post by vlovich123 »

majewsky wrote: post #87
vlovich123 wrote: post #82

Earlier quoted context omitted.

You make some good points but I think it's incorrect to compare Rust & Go. Rust is a systems programming language. It competes with C/C++ more than other high-level languages. In fact, while Go was originally positioned as a systems language but it ended up attracting people from scripting languages like Python because its performance characteristics put it there. You'd probably never bother building a serious web br…

> In terms of correctness, I've never heard claims about improving security issues I would argue that the rest of your paragraph talks about how Rust (indirectly) improves security issues. > As for compiler errors not helping you understand the problem, I have yet to encounter a compiler that does that. Try misplacing a { in an average LaTeX document. But don't say that you haven't been warned. ;) Alternatively, writ…

> I would argue that the rest of your paragraph talks about how Rust (indirectly) improves security issues.

I think perhaps I didn't communicate my meaning clearly enough. Rust does significantly reduce the risk of a certain class of security problems (reduce not eliminate since it's highly unlikely you'll have 0 unsafe{} blocks anywhere in your dependency chain). That's not disputable since that's part of the language design. That's certainly an advantage it has over C/C++. However, security is far more than just memory safety & I have read nowhere that writing more secure code is a design goal for Rust (I'm not even sure yet such a thing is possible).

> Try misplacing a { in an average LaTeX document. But don't say that you haven't been warned. ;)

> Alternatively, write some C++ code that uses std::map or something like that incorrectly, and marvel at the page-long exceptions with all the default template arguments expanded into an unreadable mess.

I agree 100%. I think perhaps you misread what I wrote? I said I have not encountered a compiler where the errors helps you understand a language.

> Is there a standard tool-enforced coding style for Rust that the community agrees on, in the same way that the Go community has by and large agreed on gofmt?

rustfmt

Re: Why is Rust difficult?

#118

Post by phyrex »

josephg wrote: post #76
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…

Have you looked at Clojure’s core.async? It’s a port of Go’s concurrency model to Clojure.

Re: Why is Rust difficult?

#119

Post by coldtea »

vlovich123 wrote: post #112
coldtea wrote: post #92

Earlier quoted context omitted.

> In terms of correctness, I've never heard claims about improving security issues, except in so far as those caused by memory/concurrency - think of it as necessary but not sufficient for security. Huh? Those might not be sufficient, but are the source of 99% of security issues.

Spectre & meltdown would like to have a word with you. Yes, memory/concurrency are a large class of problems for C/C++, but plenty of security issues still exist in other languages (check out the CVE count for Django for instance). The thing about security is that attackers will predominantly use the path of least resistance. As prevention evolves so does the sophistication & vector of attacks (e.g. timing attacks at…

>Spectre & meltdown would like to have a word with you.

Both are highly atypical, once in a decade, CPU issues, so represent 0% of software related bugs.

Re: Why is Rust difficult?

#120

Post by kilburn »

vlovich123 wrote: post #82
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…

You make some good points but I think it's incorrect to compare Rust & Go. Rust is a systems programming language. It competes with C/C++ more than other high-level languages. In fact, while Go was originally positioned as a systems language but it ended up attracting people from scripting languages like Python because its performance characteristics put it there. You'd probably never bother building a serious web br…

> As for compiler errors not helping you understand the problem, I have yet to encounter a compiler that does that.

Not very mainstream, but take a loot at elm's compiler errors [1]. They worked hard in this direction, and the result is both helpful and beautiful.

You can try loading up any of the examples in the online editor [2] and introducing a random bug, just to see how the compiler barks tries to gently teach you.

[1] http://elm-lang.org/blog/compiler-errors-for-humans

[2] http://elm-lang.org/examples

Post reply on HN