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

Rust 1.24

blog.rust-lang.org

Post reply on HN
Print view View original

131–140 of 215 posts

Re: Rust 1.24

#131

Post by ZenoArrow »

sp0ck wrote: post #126
ZenoArrow wrote: post #124

Earlier quoted context omitted.

If that's your impression, then I'd suggest Python is used for more than you're currently aware of. Here are two examples of Python being used for "low level stuff": https://micropython.org/ http://www.myhdl.org/

Nothing against Python (I'm using it) , but those solutions have huge performance impact comparing C/Rust on bare-metal. Interrupt handling, GPIO operations are orders of magnitude slower in python. Take such simple board and run basic bit-banged gpio PWM. You need "beefy" Cortex-M family to get similar performance that you can get with 8/16-uC with C. Nice for hacking stuff but I would't trust my AC conditioner firm…

> "those solutions have huge performance impact comparing C/Rust on bare-metal"

I didn't suggest Python is the optimal solution for low level coding, I just suggested it is an option.

> "You need "beefy" Cortex-M family to get similar performance that you can get with 8/16-uC with C."

In the case of MicroPython, people find it usable on platforms like the ESP8266, which is less powerful than a "beefy" Cortex-M. As before, I don't deny that there is a performance overhead compared to C, but it clearly has some traction in the embedded space.

Re: Rust 1.24

#132

Post by pvg »

ZenoArrow wrote: post #128
pvg wrote: post #125

Earlier quoted context omitted.

As they're both Turing-complete The moment you trot that out, you lose your 'but your analogy is terrible' privileges by default, however terrible my analogy is.

How so?

Because more or less everything is Turing-complete. Your mom is probably Turing-complete. 'Your mom' is a pithy but lousy argument.

Re: Rust 1.24

#133

Post by ZenoArrow »

pvg wrote: post #132
ZenoArrow wrote: post #128

Earlier quoted context omitted.

How so?

Because more or less everything is Turing-complete. Your mom is probably Turing-complete. 'Your mom' is a pithy but lousy argument.

> "Because more or less everything is Turing-complete."

If you understand what it means, then you'd know that it means that all programming languages are comparable, from assembly to Haskell, in the sense they can all be used to do the same job. Therefore, requesting a comparison of the strengths and weaknesses of two programming languages is not a foolish request. The point of such a request is to find out where it makes sense to use a particular language. To give another example, let's say someone asks if it's a good idea to write a web server in assembly or in Go. It's certainly possible in either, but in order to explore what the best choice is then further discussion is required. Comparing a Dremel to a plasma cutter is an attempt to shut down this discussion, which doesn't help in furthering the knowledge of the participants.

Re: Rust 1.24

#134

Post by pvg »

ZenoArrow wrote: post #133
pvg wrote: post #132

Earlier quoted context omitted.

Because more or less everything is Turing-complete. Your mom is probably Turing-complete. 'Your mom' is a pithy but lousy argument.

> "Because more or less everything is Turing-complete." If you understand what it means, then you'd know that it means that all programming languages are comparable, from assembly to Haskell, in the sense they can all be used to do the same job. Therefore, requesting a comparison of the strengths and weaknesses of two programming languages is not a foolish request. The point of such a request is to find out where it…

If you understand what it means, then you'd know that it means that all programming languages are comparable

I think this is where we strongly diverge and I resent, a bit, your implication that because I don't buy into this I somehow 'don't understand what it means'. I understand what it means. I just think it's plainly ridiculous.

Re: Rust 1.24

#135

Post by coldtea »

civility wrote: post #108
pcwalton wrote: post #104

Earlier quoted context omitted.

I don't know what this means.

It means things don't usually get better until you admit they're not as good as they can be.

I hope you see the irony in accusing them of that in a post announcing that the compiler just got better.

Re: Rust 1.24

#136

Post by coldtea »

civility wrote: post #99
pcwalton wrote: post #75

Earlier quoted context omitted.

> There were compilers in the 90s which ran a million lines per second (on much slower computers). Those compilers performed nowhere near the level of optimization that modern compilers do. > I'm sure some of the LLVM optimization passes are expensive, but those are used in clang++ too, and it's not terribly slow. clang++ is sure slow if it has to rebuild an entire codebase from scratch. The main reason that C++ comp…

Not going to budge an inch, eh? It must be as good as it will ever get.

Is it they who didn't "budge an inch", or you, that despite a reasoned explanation, insist on the original accusation?

Not to mention the underlying insinuation, that the Rust compiler developers are dumb for not being able to get at the 80s compiler's level of speed -- since you don't seem to accept that this is a byproduct of the advanced optimizations and security guarantees they do.

Re: Rust 1.24

#137

Post by lmm »

FullyFunctional wrote: post #48
lmm wrote: post #39

Earlier quoted context omitted.

When you work with the type system it checks a lot more than you check in Python. In Python you pass around untyped tuples and maps because defining classes won't gain you anything (and is surprisingly cumbersome and unpythonic), whereas in an ML-family language like Rust you use lightweight, fine-grained types to check that every function call is correct and you can refactor fearlessly. (I'd recommend using a langua…

Well, O'Caml and Haskell predates Rust by decades. I was delighted to see Sum-Product types in Rust when I played with it. They go a long way to cleanly model the problem domain. Obviously you can simulate them, but it's much easier to get wrong or "cheat" (say having a bunch of fields, only some of which are valid depending on a tag).

> I was delighted to see Sum-Product types in Rust when I played with it. They go a long way to cleanly model the problem domain.

Umm yeah, they've been a part of every ML-family language since the '70s, OCaml, Haskell and Rust included.

Re: Rust 1.24

#138

Post by coldtea »

kibwen wrote: post #80
dsymonds wrote: post #70

Good to see rustfmt arrive. Sad that it is configurable, though. The biggest benefit of its predecessors such as gofmt is that they are not configurable, leading to a much more uniform formatting style and avoiding endless discussions about whitespace layout.

I don't agree. There is a default configuration, and that configuration is very good (I've been following the process of nailing it down, and IMO it's been done very tastefully), and is the formatting used by official Rust codebases, lending it the weight of authority. I have no reason to configure it to do anything differently. But I also have no reason to forbid anyone else from formatting code as they please. What…

>But I also have no reason to forbid anyone else from formatting code as they please. What's the possible harm?

Obviously the proliferation of coding formatting styles. It's not we didn't have "official styles" and formatting tools before for other languages.

The greatness of gofmt, and what people love it for, is how it killed all other options.

Re: Rust 1.24

#139

Post by ComputerGuru »

civility wrote: post #108
pcwalton wrote: post #104

Earlier quoted context omitted.

I don't know what this means.

It means things don't usually get better until you admit they're not as good as they can be.

I’m pretty sure no one in their right mind claims that rustc is “as good as can be.”

It’s called incremental progress.

Re: Rust 1.24

#140

Post by cakoose »

sametmax wrote: post #121
civility wrote: post #108

Earlier quoted context omitted.

It means things don't usually get better until you admit they're not as good as they can be.

The rust compiler provide huge guaranties no other provide, like for memory safety. This has a performance impact.

The memory safety checking (or more generally, the type checking) isn't what makes the compiler slow. That part is pretty fast because it's intentionally modular.

It's the cross-module optimizations that make the compiler slow. Those optimizations are in service of C++-inspired ideal of being able to use layers of abstraction to make your code cleaner, but having the compiler flatten them down so your program still runs fast.

Post reply on HN