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

Four years with Rust

words.steveklabnik.com

Post reply on HN
Print view View original

181–190 of 199 posts

Re: Four years with Rust

#181

Post by xorxornop »

dispose13432 wrote: post #81
amelius wrote: post #47

Earlier quoted context omitted.

Reference counting can be a useful memory management technique. But reference counting may cause unpredictable pauses when large amounts of objects suddenly need to be freed (e.g. when dropping the last reference to a large array holding many references). At least a carefully written garbage collector can free objects incrementally, and concurrently. So memory management in Rust is certainly not a solved problem. EDI…

>Reference counting can be a useful memory management technique. But reference counting may cause unpredictable pauses when large amounts of objects suddenly need to be freed (e.g. when dropping the last reference to a large array holding many references). How is it compared to other forms of GC?

More performant, generally, particularly considering the fine-grained control it offers. However, cyclic datastructures may be problematic (similar to how they are in typical GC, but often worse). Of course, exceptions abound; the "better" choice is extremely use-case dependent.

Re: Four years with Rust

#182

Post by xorxornop »

gedrap wrote: post #165
prewett wrote: post #134

Earlier quoted context omitted.

Are you talking about strong typing or static typing? I've been using statically typed languages for 20 years (C++, Java, Objective-C) and I haven't gotten tired of it yet. Especially when working in a large code-base I didn't write, Python is rough. What's a "session"? Who knows, guess I'd better put `print type(session)` and figure out how to get that function executed. Although, the thing that bothers me about Pyt…

> until you execute that line of code to make sure there wasn't a misspelled variable name or something But isn't it the purpose of tools such as IDEs? PyCharm is pretty damn good at it. Of course, it's not always possible or convenient firing up an IDE. But I suppose editors such as vim should be fully capable of doing this via plugins as well.

The best use case I know of is avoiding the common Python & Ruby pitfall of "just stick everything in a dictionary and index it by key". Welp, forgot to update every instance of that string index (particularly if that name overlaps with anything else, including variable and function and class names... so, like, a lot of the time).

Re: Four years with Rust

#183

Post by Annatar »

GolDDranks wrote: post #176
Annatar wrote: post #164

In today’s Rust, this would be an error, you need to write (e.f)(); At least the error tells you exactly what to do! If the programmer knows what the error is, and how to correct it, then their program should automatically do so, rather than molesting the user, as the purpose of computers is to speed up and automate. Why should the user have to foot the designers' bills? Another cardinal sin and a sign of lack of thi…

It's not the job of the compiler to speed up and automate _editing_code_. That's the job of an IDE. And we have a unfolding story for that: Rust Language Server, or RLS for short, which is a package providing pluggable Rust IDE-functionality for all kinds of text editors. Besides, the change we are talking about happened 4 years ago, when Rust emphatically did NOT have any compatibility guarantees and was in a proces…

It's not the job of the compiler to speed up and automate _editing_code_.

Calling changing the syntax on unsuspecting users _editing_code_ is really a stretch of gargantuan proportions. And I don't really care whether it's the compiler, the linker, or mega_mojo-2.546-alfa5-preview18, what ever it is, it runs on a computer so that whatever is being done would be fast, automated, and therefore efficient. If the programmer knew what to do with the input, the computer should churn through it, instead of chastizing the user and making them pay for the authors' oversight.

Otherwise, a computer makes no more sense than a toy does.

If I want to use a computer as a toy, I'll go play a video game. The rest of the time, it's a tool, a tool to do something an order of magnitude faster than a human could. If it slows me down because it requires me to babysit it, I have a problem.

Re: Four years with Rust

#184

Post by xorxornop »

oblio wrote: post #169
steveklabnik wrote: post #22

Earlier quoted context omitted.

Yes, a split like this would be undesirable to say the least. Not to mention that systems people are used to near-total backwards compatibility; any sort of near-term timeframe for such a thing would destroy a lot of our credibility, in my personal opinion. I'm on team "never 2.0". We still have some desire to indicate "epochs" of Rust development, as undoubtedly, things like idioms will change over time, new librari…

Maybe compiler profiles? So that a project can say -rust2018 and disallow bad practices from pre-2018?

Yeah. Basically linting profiles. Reminds me of some proposals I've read about reducing the complexity of C++ without creating an actual subset or superset.

Re: Four years with Rust

#185

Post by xorxornop »

Annatar wrote: post #183
GolDDranks wrote: post #176

Earlier quoted context omitted.

It's not the job of the compiler to speed up and automate _editing_code_. That's the job of an IDE. And we have a unfolding story for that: Rust Language Server, or RLS for short, which is a package providing pluggable Rust IDE-functionality for all kinds of text editors. Besides, the change we are talking about happened 4 years ago, when Rust emphatically did NOT have any compatibility guarantees and was in a proces…

It's not the job of the compiler to speed up and automate _editing_code_. Calling changing the syntax on unsuspecting users _editing_code_ is really a stretch of gargantuan proportions. And I don't really care whether it's the compiler, the linker, or mega_mojo-2.546-alfa5-preview18, what ever it is, it runs on a computer so that whatever is being done would be fast, automated, and therefore efficient. If the program…

That's all well and good if the context is unambiguous, but if it isn't, people will get used to having this done for them (or not even know that it happens at all), and then be totally perplexed. Worse, maybe then people want even ambiguous situations to be made friction-free, so the compiler must guess. Then you've got the possibility of very confusing behaviour, doubly so if the ambiguity involves any kind of polymorphism (different, possibly contradictory behaviour per type!)

Re: Four years with Rust

#186

Post by erikpukinskis »

sowhatquestion wrote: post #167

I'm highly curious about Rust as a potential introduction to systems programming. One thing that bothers me is the lack of proper classes. This seems to have become a trend among newer languages, as though traditional OOP is an outdated paradigm. I have yet to be convinced that this is a good move. The attempted justifications I've seen hand-wave about problems with OOP, "composition over inheritance," etc. Meanwhile…

In the real world 99% of vehicles burn petroleum and the paradigm continues to do is basic job.

Re: Four years with Rust

#187

Post by steveklabnik »

losvedir wrote: post #116

Wow, four years already. Maybe you can help settle this question I've had. I'm a rubyist (like you were/are, and wycats, and a bunch of rustaceans), and I think that sort of drove my interest in rust. But after 4-5 years of ruby the dynamism which initially was super cool, has grown a little frustrating and I long for a more sophisticated type system and a compile step, since frustrating bugs crop up from time to tim…

This is very thoughtful :)

So I _do_ like Rust for other reasons, or at least, I did initially. My opinion has changed over time. I used to say "I'd never write web application in Rust," but soon, I'd prefer it slightly. Needs some more libraries to come out, and they're close...

There's two sides to "is the flipside true"? One is, there's a huge variety of static type systems. Some of them are more flexible than others. So for example, if I had to use Java 1.4, or even Java 1.5 (which are very old, but were two releases I am very familiar with), I'd wish I was back in Ruby. This is because it's _too_ rigid; I can't express enough things in the type system to make up for the lack of flexibility. In a language with a better type system (and Java itself has a better one today, even), it changes the value of the equation.

In Rust though, there's another axis: speed, memory usage, stuff like that. I don't miss Ruby's flexibility here, because even basic operations in Ruby are _so so so_ much more expensive than in Rust. So when I think "oh yeah, I could do that, but if I think about how Ruby does it under the hood... it's not worth the cost." This makes me miss Ruby less as well.

Ruby is an excellent language, and I will always love working with it. But there's only so many hours in the day, and I've spent so much time with it already...

Re: Four years with Rust

#188

Post by iopq »

flukus wrote: post #154
iopq wrote: post #150

Earlier quoted context omitted.

In Rust, you'd define an `enum` of two types. enum Either { Type1(T1), Type2(T2), } let's say you get a value of type Either then you can match on them: match value { Type1(v) => func(v), Type2(v) => func2(v), }

Does that let you work with the default type? What I was doing in c#: function(T1 thing) { //do normal T1 stuff here var foo = arg as T2; if (foo != null) foo.T2Stuff(); //more normal T1 stuff } If I'm understanding your example I would have to wrap all the T1 stuff in a match.

Yes, you'd have to wrap it in a match. But maybe you don't have to.

If T1 is the normal case, then there's a type in Rust called Result that handles this kind of pattern.

    fn potentially_failing(thing: Result) {
        thing.map(|foo| success_case(foo));
    }
this will only execute in the success case and ignore the error case

map_err does the same, but only touching the error case

Re: Four years with Rust

#189

Post by fredsir »

gedrap wrote: post #165
prewett wrote: post #134

Earlier quoted context omitted.

Are you talking about strong typing or static typing? I've been using statically typed languages for 20 years (C++, Java, Objective-C) and I haven't gotten tired of it yet. Especially when working in a large code-base I didn't write, Python is rough. What's a "session"? Who knows, guess I'd better put `print type(session)` and figure out how to get that function executed. Although, the thing that bothers me about Pyt…

> until you execute that line of code to make sure there wasn't a misspelled variable name or something But isn't it the purpose of tools such as IDEs? PyCharm is pretty damn good at it. Of course, it's not always possible or convenient firing up an IDE. But I suppose editors such as vim should be fully capable of doing this via plugins as well.

Yeah, no, I don't think that is the job for an IDE. Maybe for you on your desktop, but your software should work regardless of any IDE or editor.

Re: Four years with Rust

#190

Post by alblue »

xorxornop wrote: post #178
alblue wrote: post #171

Earlier quoted context omitted.

Garbage collection requires a garbage collector, which reference counting doesn't have or need. This is true for both academia and industry.

It's still runtime memory management. That makes it garbage collection in my book. Sure it's not as involved as tracing, the prototypical form of GC, but it's still something that requires a runtime check each time that resource is used or a binding to it goes out of scope, similar to aspects in generational GC.

The point is that while both reference counting and garbage collection are types of automatic memory management, the reverse isn't true.

From a 1976 paper on automatic memory management https://www.cs.purdue.edu/homes/hosking/690M/deutsch.pdf

"Automatic reclamation of storage no longer in use is done by the following two techniques:

* Garbage collection * Reference counting"

Note that these are two separate items and that one is not a subset of the other (and vice versa). It is simply incorrect to call reference counting "garbage collection" when the academic and industrial practices already have explicit meanings to these two terms.

Post reply on HN