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

The Rust I wanted had no future

graydon2.dreamwidth.org

Post reply on HN
Print view View original

91–100 of 523 posts

Re: The Rust I wanted had no future

#91

Post by mike_hearn »

ohgodplsno wrote: post #86
mike_hearn wrote: post #57

Earlier quoted context omitted.

Async doesn't solve that problem. What you're asking for is some sort of expression in the type system of expected performance, but there's no tech that can do this. Consider that modern NVMe SSDs can do disk reads faster than many calculations over the content of what was just read. A function that changes its algorithm to have worse time complexity won't be marked as async but could break your app, adding a single…

Adding a disk read won't break my software, but it can certainly make my software non-portable. If it suddenly expects a disk write and I'm running on a ROM, I'm going to have a hard time. If it suddenly tries to contact google.com and I'm on an airgapped machine, I'm going to have a hard time. It's not even a matter of breaking the app actually, it's a matter of warning that "I'm going to go outside the realm of jus…

Blocking in Loom is primarily about waiting for network traffic, possibly with extensions to file IO in future - it doesn't suspend if you do file IO today. Loom does get rid of coloring, or rather, doesn't introduce more of it and lets you phase out what exists, so I'm not sure what exactly you mean by that.

Kotlin suspend funs do not tell you they're about to touch network disk, that's the reason they use "suspend" and not "async". Suspend funs can also use generators (with yield) in which case no I/O is happening but they are nonetheless suspending.

So this is why blocking as a concept isn't a great one, IMO. The Kotlin designers were right to not use the word in their implementation of coroutines. Where Loom discusses blocking a bit, it's not defined as being about blocking, it's about being able to scale up threads to way beyond what was previously possible. It just so happens that the primary reason you'd want to do that is if you have lots of threads that spend lots of time waiting for things, but that doesn't automatically require network or disk access. For example you can use threads that spend all their time in Thread.sleep if you were writing an agent simulation.

Re: The Rust I wanted had no future

#92

Post by layer8 »

Aissen wrote: post #12

On integer wrapping, I think explicit wrap is annoying at first, but eliminates a whole class of bug. I can only agree with: > (Swift at least traps in release by default -- I wish Rust had chosen to). I enable it in release on serious projects: [profile.release] overflow-checks = true

The correct (but hard) way to prevent overflow-related bugs would be to insist on the compiler being able to prove that no overflow can occur. Basically the same thing you do in your head to convince yourself that the program is correct and won’t overflow, only in a more formally rigorous fashion. Modulo semantics by itself doesn’t prevent bugs.

Re: The Rust I wanted had no future

#93

Post by rcxdude »

nsajko wrote: post #5
skellington wrote: post #4

Earlier quoted context omitted.

Committees tend to design less beautiful things. Look at modern c++ too. What a mess. Everyone in the committee has to jam in their favorite feature, much of which is sugar.

Modern C++ is actually going relatively OK? You may be thinking of the old, pre-C++11 C++?

I don't think that modern C++ is any less messy than old C++. If anything it's more so, as even more difficult conscessions to backwards compatibility emerge. That's not the say the new functionality isn't useful, but I don't think it cleans anything up. Modern C++ is approaching an order of magnitude more complexity than pre-C++11 (which is not surprising if you are adding features but not removing or changing old functionality), and I don't think it's a sustainable increase.

Re: The Rust I wanted had no future

#94

Post by mike_hearn »

hayley-patton wrote: post #75
mike_hearn wrote: post #57

Earlier quoted context omitted.

Async doesn't solve that problem. What you're asking for is some sort of expression in the type system of expected performance, but there's no tech that can do this. Consider that modern NVMe SSDs can do disk reads faster than many calculations over the content of what was just read. A function that changes its algorithm to have worse time complexity won't be marked as async but could break your app, adding a single…

There are type systems which can track complexity (e.g. http://gallium.inria.fr/~fpottier/slides/fpottier-2011-01-jf... ) but that's still different to performance; async/sync tells us things like "touches disk" or "touches network" but not "O(2^n) might take a really long time". Alternately, an effect system can communicate "touches disk", can make functions which are polymorphic to effects (e.g. map touches the dis…

Yes, but are there any effects systems in use outside of maybe Haskell? Effects seem mostly to be stuck in the research lab and have been for a long time.

Re: The Rust I wanted had no future

#95

Post by rcxdude »

nsajko wrote: post #59
Sankozi wrote: post #28

Earlier quoted context omitted.

If you have a mess and add something to it, you still have a mess, probably a bigger one. To clean the mess you need to remove something (which is really hard in a programming language) not to add something. Selecting and enforcing usage of a subset of C++ is a way to deal with that mess which companies frequently use.

Everything is a mess. The universe is a mess. That doesn't make perfectionism a good thing. Besides, the C++ committee does, in fact, remove stuff from the language to clean the mess, just not without due care.

They do so once in a blue moon, and only for ideas so spectacularly bad that either they were never implemented or never used by anyone. Those aren't the main problem with C++ mess, the issue is the many small but important details which are deeply embedded into the language since it started as a super-set of C.

Re: The Rust I wanted had no future

#96

Post by eru »

elcritch wrote: post #3
jstx1 wrote: post #2

A bunch of things you don't like about Rust? Turns out that the person who originally created the language doesn't like them either. I know that the main point is about governance and how having a BDFL would have led to a completely different language but I really would have preferred the Graydon-BDFL-Rust to what we have today. Very interesting article, worth a read.

One highlight from the article: > Traits. I generally don't like traits / typeclasses. To my eyes they're too type-directed, too global, too much like programming and debugging a distributed set of invisible inference rules, and produce too much coupling between libraries in terms of what is or isn't allowed to maintain coherence. Very much this! > I wanted (and got part way into building) a first class module system…

Having used both OCaml and Haskell in production, I can say that the typeclass way of doing things is massively more convenient.

But I guess enough syntactic sugar might make things palatable.

Re: The Rust I wanted had no future

#97

Post by eru »

skellington wrote: post #4
jstx1 wrote: post #2

A bunch of things you don't like about Rust? Turns out that the person who originally created the language doesn't like them either. I know that the main point is about governance and how having a BDFL would have led to a completely different language but I really would have preferred the Graydon-BDFL-Rust to what we have today. Very interesting article, worth a read.

Committees tend to design less beautiful things. Look at modern c++ too. What a mess. Everyone in the committee has to jam in their favorite feature, much of which is sugar.

Haskell is designed by committee, and it's a fairly alright language.

Re: The Rust I wanted had no future

#98

Post by hayley-patton »

mike_hearn wrote: post #94
hayley-patton wrote: post #75

Earlier quoted context omitted.

There are type systems which can track complexity (e.g. http://gallium.inria.fr/~fpottier/slides/fpottier-2011-01-jf... ) but that's still different to performance; async/sync tells us things like "touches disk" or "touches network" but not "O(2^n) might take a really long time". Alternately, an effect system can communicate "touches disk", can make functions which are polymorphic to effects (e.g. map touches the dis…

Yes, but are there any effects systems in use outside of maybe Haskell? Effects seem mostly to be stuck in the research lab and have been for a long time.

I don't mean "effects" in the sense where you can have effect handlers which get delimited continuations and all; it'd just mark what could happen (like checked exceptions). But I can't think of any languages with that and not effect handlers; Koka, Eff, and Unison come to mind for effects, though their practical-ness may vary.

Re: The Rust I wanted had no future

#99

Post by glandium »

Gwypaas wrote: post #87
glandium wrote: post #55

Earlier quoted context omitted.

There's worse. When your trait adds function foo and your code does obj.foo(), if the underlying type later adds a foo method, compilation breaks. This is very common with traits that usefully add useful methods that are missing in libstd... which break when said method is finally added there.

I ran into this case yesterday, for some cases there are warnings now. In this case I used ".div_ceil(...)" from from the Num [0] crate. (some_integer).div_ceil(&2) ^^^^^^^^ = warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior! = note: for more information, see issue #48919 = help: call with fully qualified syntax `num::Integer::div_ceil(...)` t…

This warning happens during the time the method is added to libstd but is still unstable.

Re: The Rust I wanted had no future

#100

Post by inferiorhuman »

vsnf wrote: post #85
inferiorhuman wrote: post #68

Earlier quoted context omitted.

Hard disagree. Rust brings a lot to the table for a web app. Compiled vs interpreted makes it easier to catch (syntax) errors beforehand. You can even go as far as compiled templates. Mapping JSON (or whatever) to strongly typed objects is great . Dependency management is best in class. I rather like diesel.rs (although it is very much an acquired taste) especially if you treat it like a safe query builder rather tha…

Although all of those things are true, I think the main point being made is why choose Rust for that, instead of Go, .NET, etc, any of which offer everything you've outlined as being worth having, while having fewer of the downsides of Rust.

  any of which offer everything you've outlined
They don't, that's the "problem". Off the top of my head dependency management in Go is not best in class to put it charitably. .NET will tie you more closely to Windows. Sure, mono is a thing but you'll have more packages to choose from and fewer compatibility issues running .NET on Windows.
Post reply on HN