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

Rust 1.49.0

blog.rust-lang.org

Post reply on HN
Print view View original

111–117 of 117 posts

Re: Rust 1.49.0

#111

Post by Galanwe »

lights0123 wrote: post #85
Galanwe wrote: post #67

Any chance to see increased support for 8bit AVR in upcoming releases? I know Rust is community driven, so it's not like contributions will appear from thin air. But I guess maybe it would be time to promote/incentivize people to contribute support for microcontrollers. This is a realm where C reigns and Rust would be a bowl of fresh air.

Rust has full support for AVR, excluding function pointers due to current LLVM bugs. Building on stable would be nice though, as it currently requires a custom target JSON file.

> Rust has full support for AVR

Last time I checked (6 month ago), the Rust AVR fork had just been merged upstream. This removed the necessity to build a forked rustc from a patched llvm.

I would have to re-check recent updates, but at the time there were still a lot of bugs, no core libs, etc.

That's not what I would call "full support".

Re: Rust 1.49.0

#112

Post by UtherII »

apta_ wrote: post #105

What IDE do people use for rust nowadays?

The IDE support use to be very poor but nowadays there are two really nice contenders :

- Jetbrains IDE with the Rust plugin (maintained by Jetbrains itself). The free IntelliJ IDE Community works really well. CLion or IntelliJ Ultimate are necessary for debugging support

- The Rust-analyser tool. A language server that can be used, in theory, on any IDE supporting the LSP protocol. Code is the most used IDE with this tool since it is the reference IDE of the project.

Re: Rust 1.49.0

#113

Post by boxmonster »

j1elo wrote: post #73
boxmonster wrote: post #19

I recently wrote a utility for myself in Rust after having done several in C#. I like both languages, but Rust introduces pain points for no apparent reason. For example, I hate this way of dealing with errors match result { Ok(value) => value, Err(result) => { panic!("error traversing directories {}", result); } }; It's awkward and ugly. I'm back to C#, now on .NET 5.) and find that it just got noticeably faster! It…

"I recently wrote a utility for myself in ASM after having done several in C. I like both languages, but ASM introduces pain points for no apparent reason." IMO the_duke summarized it perfectly in other comment: You are essentially complaining that Rust is not C#; Rust is much lower level and makes very different tradeoffs; most of the design decisions are there for a reason, and are good choices ( https://news.ycomb…

HN won't let me edit my comment to clarify (after 2 hours?) but I was pleasantly surprised that Rust felt like C# to me and I didn't have to struggle much because I already know about references, pointers, stacks and heaps (from C and asm) Dictionaries and Lists were easy to work with. I grokked the borrow checker. I was motivated to make my post because I struggle with the various return types and syntax like

    enum Result {
       Ok(T),
       Err(E),
    }

    match header.get(0) {
        None => Err("invalid header length"),
        Some(&1) => Ok(Version::Version1),
        Some(&2) => Ok(Version::Version2),
        Some(_) => Err("invalid version"),
    }
I wasn't saying it was bad, just a pain point for me.

Re: Rust 1.49.0

#114

Post by ithkuil »

majewsky wrote: post #91
the_duke wrote: post #56

Earlier quoted context omitted.

rustup is still the recommended way to install. Rust has a 6 week release cadence, and while the language has settled down significantly over the last 1-2 years, there are still a lot of new features arriving that library maintainers are eager to use. Combined with performance improvements, you will almost always want to use a recent compiler. Relatively slow moving package repositories are not a great fit for that r…

> Relatively slow moving package repositories are not a great fit for that reason Not every distribution is Debian Stable.

It seems that ubuntu 20.10 groovy gorilla is stuck at 1.43

As a library maintainer I need to make the choice of which version to target.

It's easy to accidently use features of a recent rust version, as you can see in this example:

https://github.com/mkmik/slyce/issues/17

I could work around this issue and pin the rustc version in the CI system to avoid regressions, but is it worth the effort since it's likely that this particular user will eventually depend on another library that uses a feature of >1.43 and thus eventually give in and use rustup? I want to be helpful towards users of my library, but I wonder if the most rational choice is to encourage users to upgrade the toolchain more liberally.

Re: Rust 1.49.0

#115

Post by Measter »

glandium wrote: post #104
Measter wrote: post #96

Earlier quoted context omitted.

Unfortunately that is not always the case. This fails to compile, for example (and is fairly irritating): let my_str = "Hello".to_owned(); match &my_str { "Hello" => (), _ => () }

try &*my_str

Yes, that's the trivial "fix" to make it work, but that's not my point. In most other similar situations the compiler does that for me, but not here. It feels like something the compiler should be doing, not me.

Re: Rust 1.49.0

#117

Post by steveklabnik »

candied_scarf wrote: post #116

i am disappoint there isnt mention of more private/reproducible release binary output from compilation https://github.com/rust-lang/rust/issues/40552 https://github.com/rust-lang/rust/issues/75263

This bugs are still open, so there’s no reason to talk about them in a release announcement. If they were fixed, and made it into a release, then there’d be more to talk about.
Post reply on HN