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

Announcing Rust 1.24.1

blog.rust-lang.org

Post reply on HN
Print view View original

51–60 of 66 posts

Re: Announcing Rust 1.24.1

#51

Post by varjag »

rkangel wrote: post #48
varjag wrote: post #22

Earlier quoted context omitted.

The better half of those points are directly and indirectly caused by insistence on manual memory management. Yes, it was a major design point of Rust, but it doesn't make it better engineered than "most other languages". It's just the corner it painted itself to.

If you have no need for the use case of a high speed, low overhead non-GC language (or believe there is no need for such a thing), then Rust is going to be of no interest to you, and you are going to be better served solving your problems with another language - Java, C#, Python etc. A large number of engineers do desire such a tool, and Rust provides that in a way that provides as little cost as possible over one of…

You are answering a point I didn't make. I addressed the stated 'engineering supremacy'.

Re: Announcing Rust 1.24.1

#52

Post by colejohnson66 »

amluto wrote: post #49
Arnavion wrote: post #24

Earlier quoted context omitted.

>Why are developers (since this is an issue that shows up with cargo) running Windows 7 without security patches installed? Especially since the issue only shows up on Windows 7 installs that haven't received security patches since June 2016. The issue shows up on patched machines. The patch does not enable TLS 1.2 by default. You have to add reg keys for it. https://github.com/rust-lang/cargo/issues/5065#issuecommen…

I've never understood why Microsoft adds support for new crypto protocols but turns them off by default.

To avoid breaking badly designed programs?

Re: Announcing Rust 1.24.1

#53

Post by steveklabnik »

stuaxo wrote: post #47
devit wrote: post #16

Earlier quoted context omitted.

Because unlike most other programming languages, Rust is well-engineered and seeks to both provide the most general abstractions possible and to make the code generated by them as efficient as possible. In particular, for this task, this requires to: 1. Return references to subranges of the original string, rather than copying them, so that no copy happens if you only need to examine the component instead of storing…

Echoing the other commented, it would be great if the docs had a "why?" link to this.

It's extremely hard to know when someone needs a "why?" link. This is the kind of information that's conditional, which is the hardest part of API docs.

Re: Announcing Rust 1.24.1

#54

Post by steveklabnik »

ndh2 wrote: post #45
devit wrote: post #16

Earlier quoted context omitted.

Because unlike most other programming languages, Rust is well-engineered and seeks to both provide the most general abstractions possible and to make the code generated by them as efficient as possible. In particular, for this task, this requires to: 1. Return references to subranges of the original string, rather than copying them, so that no copy happens if you only need to examine the component instead of storing…

Good read. Too bad none of that made it into the documentation.

So, a lot of it is in the documentation, but if you don't know Rust, then you might not infer it. This kind of thing is tough, as you need to balance audiences. The API docs assume you already know Rust.

For example:

Point 1 is known because the Item type is &str.

Point 2 is known because, well, that's the norm, but beyond that, SplitWhitespace is parameterized over a lifetime

Point 3 is known because it's an iterator; next() is its primary interface, which returns things one by one.

Point 4 is the "impl Iterator" bit

Point 5 is known because the return type of split_whitespace is this iterator, not Box

Point 6 is related.

If we repeated all of this stuff in every single bit of docs, it might make it more useful for some audiences, but also kinda destroy the docs for intermediate/advanced Rust users.

I'd love to make docs generally more accessible, but I'm not aware of any great solutions to this particular problem.

Re: Announcing Rust 1.24.1

#55

Post by rkangel »

varjag wrote: post #51
rkangel wrote: post #48

Earlier quoted context omitted.

If you have no need for the use case of a high speed, low overhead non-GC language (or believe there is no need for such a thing), then Rust is going to be of no interest to you, and you are going to be better served solving your problems with another language - Java, C#, Python etc. A large number of engineers do desire such a tool, and Rust provides that in a way that provides as little cost as possible over one of…

You are answering a point I didn't make. I addressed the stated 'engineering supremacy'.

I am asserting that (a) Rust has made a good choice to be a 'manual memory management' language, and that (b) it has executed that well (or at least better than any other option).

Your phrase about 'painting itself into a corner' implies you disagree with point (a), and that was the case I was trying to make.

Re: Announcing Rust 1.24.1

#56

Post by the_mitsuhiko »

dom96 wrote: post #31
the_mitsuhiko wrote: post #12

Earlier quoted context omitted.

> Why would you create a special data type to represent a string split by Whitespace? Lunacy Because it's an iterator. A bespoke iterator type is also created behind the scenes in many other languages. How else would you do it?

> How else would you do it? There is a `splitWhitespace` iterator[1] in the Nim programming language as well and doesn't require a separate type. In Nim, the iterator is inlined. 1 - https://nim-lang.org/docs/strutils.html#splitWhitespace.i,st...

Iterators in nim are also weird because many of them are not first class types and cannot be assigned to variables. I do not consider that to be a particularly good concept to be honest.

Re: Announcing Rust 1.24.1

#57

Post by dom96 »

the_mitsuhiko wrote: post #56
dom96 wrote: post #31

Earlier quoted context omitted.

> How else would you do it? There is a `splitWhitespace` iterator[1] in the Nim programming language as well and doesn't require a separate type. In Nim, the iterator is inlined. 1 - https://nim-lang.org/docs/strutils.html#splitWhitespace.i,st...

Iterators in nim are also weird because many of them are not first class types and cannot be assigned to variables. I do not consider that to be a particularly good concept to be honest.

There are two types of iterators in Nim. The inlined variant is more efficient, and you can fairly easily wrap it in the other type: the "closure"" iterator. Why do you not consider it a good concept?

Re: Announcing Rust 1.24.1

#58

Post by frankmcsherry »

steveklabnik wrote: post #54
ndh2 wrote: post #45

Earlier quoted context omitted.

Good read. Too bad none of that made it into the documentation.

So, a lot of it is in the documentation, but if you don't know Rust, then you might not infer it. This kind of thing is tough, as you need to balance audiences. The API docs assume you already know Rust. For example: Point 1 is known because the Item type is &str. Point 2 is known because, well, that's the norm, but beyond that, SplitWhitespace is parameterized over a lifetime Point 3 is known because it's an iterato…

You could probably just have a link that directs the reader to HN and posts a pre-filled "I have barely read about Rust, and it all seems over-complicated and ill-designed; convince me" comment.

Re: Announcing Rust 1.24.1

#59

Post by iknowstuff »

varjag wrote: post #46
mathw wrote: post #40

Earlier quoted context omitted.

Rust doesn't have C++ constructor/destructor semantics. It doesn't require manual tracking of object ownership. You just have to say when you're passing ownership and when you aren't, and the compiler takes care of the rest. It's automatic memory management without runtime accounting or a garbage collector, which means Rust doesn't need a runtime at all.

> It doesn't require manual tracking of object ownership. You just have to say when you're passing ownership and when you aren't […] Call it whatever you want, but there are languages where you don't have to "pass ownership" manually for every frigging thing.

And you won't see them being used for systems programming because of their overhead. So without Rust, we'll be stuck with stupid, avoidable security vulnerabilities at the base of all our software, forever. On top of that, Rust's ownership system also prevents data races and none of those other languages are capable of that.

Re: Announcing Rust 1.24.1

#60

Post by __david__ »

varjag wrote: post #37
olavk wrote: post #35

Earlier quoted context omitted.

Rust doesn't have manual memory management. It does have deterministic memory management as opposed to garbage collected language. Which means you can use it it in domains where garbage collected languages cannot be used - e.g. for a OS ...or for implementing a garbage collector.

You absolutely can implement an OS or a garbage collector in a GC-enabled language.

Well, sure, if you want completely unpredictable timings on everything. GCs have real problems in certain domains.
Post reply on HN