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

271–280 of 523 posts

Re: The Rust I wanted had no future

#271

Post by logicchains »

chrismorgan wrote: post #158
logicchains wrote: post #129

Earlier quoted context omitted.

The Rust async story would be much nicer if they'd put in the hard work up front to support higher-kinded types, as then it could have a monadic async API like OCaml or Haskell. I don't know anyone who's used async in both Rust and Haskell who prefers the Rust approach. It'd also fix oddities like why it's possible to write a function like the following in C++ but not Rust: template class MyContainer> int getFirstInt…

Are you aware of generic associated types , which landed in 1.65 (late last year)? To a considerable extent, they’re Rust’s answer to higher-kinded types. Less expressive in some ways, but fitting Rust way better, as basically a relaxation of a former restriction, rather than a new feature. If I’m reading your snippet right, GATs let you express exactly that, though minus `template`’s duck-typiness so you’d have to s…

>less expressive in some ways, but fitting Rust way better, as basically a relaxation of a former restriction, rather than a new feature

They're not expressive enough to implement a monadic async library, as far as I'm aware, so they don't fulfill the role of proper HKTs in this context.

>minus `template`’s duck-typiness so you’d have to spell out what contract the container must adhere to.

Do you think it's consistent that the T in MyContainer can be "duck typed" but not the MyContainer?

Re: The Rust I wanted had no future

#272

Post by awestroke »

mjburgess wrote: post #230
kaba0 wrote: post #219

Earlier quoted context omitted.

Rust is a low-level programming language meant to control everything about the code’s execution. It will by almost definition, be complex. You seem to want contradictory things — if you don’t need that level of control just use any of the litany of high level languages with nice syntaxes. I don’t think we can eat this cake anytime.

The major innovation in this space is to make the compiler an interpreter which can evaluate the language at compile time (and emits code for runtime where it cannot). This makes brining in the "full power of dynamic languages" almost trivial and extremely performant. Delete half of rust's symbols, get rid of its macro system, rewrite it until lifetimes are inferred /or/ allocators are explicitly chosen, etc. etc. I…

> Delete half of rust's symbols, get rid of its macro system, rewrite it until lifetimes are inferred /or/ allocators are explicitly chosen, etc. etc.

Feel free to do this. I predict you will end up with a language that appeals to nobody but yourself

Re: The Rust I wanted had no future

#273

Post by yawaramin »

mjmahone17 wrote: post #170
belmont_sup wrote: post #135

Earlier quoted context omitted.

Algebraic effects like how OCaml’s now implementing it may be possible! The ecosystem around effects in OCaml is still really young, but here’s an example of an http request being made that is asynchronous, non-blocking but looks synchronous with no special syntax. https://github.com/mirage/ocaml-cohttp/blob/16e991ec1f7e5f0c... Performing these effects is similar to throwing exceptions up the callstack where whicheve…

As someone who likes OCaml, but hasn’t touched OCaml in ~5 years, that’s a very hard example to read. I can tell it’s making a network request, but I have no clue: - what the type of res is (is it a string? A buffer? Async string? Something else?) - how this code does not block: what is happening in parallel? At which point will it block? I would like to be excited about OCaml’s algebraic effects, but right now I don…

- It's some type from which you can read a response body. In OCaml we often work in terms of abstract types i.e. the operations which can be done on types. If you want to see the exact name of the type you can always look up the signature of `Client.get`: https://github.com/mirage/ocaml-cohttp/blob/16e991ec1f7e5f0c... (nowadays LSP support in any good editor will show the type on hover)

- It's implementing non-blocking I/O using effect handlers. The complexity is not exposed to the library user, which is actually the whole point. If you want to dive into the concurrency library (Eio) and study how it works, that's very doable, just like any concurrency library in any other language.

There's really not that much to get–OCaml will do async I/O without having to colour functions, just like Go, Erlang/Elixir, and soon Java. It's not something sexy like monads that excite people with mysterious FP concepts, it's just a lot of hard work that went into simplifying how developers code at scale.

Re: The Rust I wanted had no future

#274

Post by Freedom2 »

duped wrote: post #255
fzeindl wrote: post #205

Earlier quoted context omitted.

I hate async as well. Developers should have learned about communicating sequential processes and blocking queues and none of that would have been necessary. It creates a weird divide in every language. Just learn about threading and do it. A nice talk about this: https://www.reddit.com/r/programming/comments/da141r/ron_pre...

Developers should learn the difference between concurrency and parallelism because async isn't equivalent to threading.

Yep, it's pretty alarming that a developer would toss away async when threading isn't a fit for all situations - what happened to the right person tool for the job? As a professional, I 'hate' some things too, but I'm not going to blindly make my work harder and less efficient out of some small preference I have.

Re: The Rust I wanted had no future

#275

Post by svieira »

thiht wrote: post #194
viscanti wrote: post #176

Earlier quoted context omitted.

The py2 to py3 transition seems to have gone very poorly, although most of the pain from that is behind us now.

Honestly I blame the community. The transition was slow (Python 2 was supported in parallel to 3 for a long period of time so there was more than enough time to migrate), relatively easy to do, and brought huge benefits to the ecosystem. It could have been done and forgotten in 2 years if some community members had not been dicks about it.

It really seemed that the issue was mostly "Unicode is really hard if you haven't thought _deeply_ about it" because application code, library and framework code, _and_ "system" Python code had to go through several iterations of "here's how to do it right" before something reasonable came out that solved issues for most / all stakeholders. And the Swift / Raku people are still sitting on the sidelines smiling, knowing that there are a lot more "lenses" to view text through that Python doesn't make easy (but neither does Haskell, JS, or Java, so there's good company in good-enough-for-now land).

Re: The Rust I wanted had no future

#277

Post by duped »

mrkeen wrote: post #258
duped wrote: post #249

Earlier quoted context omitted.

On top of this, there's this bogus mantra in the Rust community that "if it type checks then it works." I've spent of hours interactively debugging Rust code, crawling through tracing output etc, and hours waiting for Rust code to link with mold because I added an eprintln somewhere, so I'm not convinced. I love writing Rust and think it makes my life easier, but there's this stockholm syndrome about compile times. I…

> there's this stockholm syndrome about compile times. It sucks, and it's not the type system or borrowchecker's fault. What do you mean?

The bottlenecks in Rust builds arent't type checking/borrow checking. It's things like macro expansion, module resolution and compilation, codegen from LLVM IR, and linking. Some of these things have workarounds like sccache, using mold instead of the system linker, etc but others are problems that not only remain unsolved but are actively getting worse in the ecosystem.

Re: The Rust I wanted had no future

#278

Post by netbioserror »

anonyfox wrote: post #143

I love Rust and built some production code with it in the past. But nowadays I want something more simple so that not-so-senior developers can pick it up quickly, and I want flawless tooling, and willing to sacrifice a bit of performance. So basically I often end up with Go. Go is exceptionally great in tooling, ecosystem, any objective metrics like build times or crosscompilation... but I still don't like the langua…

Nim gets real close. It doesn't have great UI tooling, but its command line tools are quite good.

Re: The Rust I wanted had no future

#279

Post by steveklabnik »

badrequest wrote: post #253
dataflow wrote: post #244

Earlier quoted context omitted.

> Rust ending up as a replacement C++ helped it If anything, it's more a C replacement than a C++ replacement. It will take some market share from both of course (and other languages to a lesser extent too), but functionality-wise, it just isn't (currently, at least) practically able to replace some C++ use cases.

I'm interested in more on this. What can I do in C++ that I can't do in Rust?

(Not your parent) Many people point to more advanced meta programming, such as variadrics, higher kinded types (though as mentioned GATs advance Rust in this general area), and specialization.

Re: The Rust I wanted had no future

#280

Post by imtringued »

thiht wrote: post #194
viscanti wrote: post #176

Earlier quoted context omitted.

The py2 to py3 transition seems to have gone very poorly, although most of the pain from that is behind us now.

Honestly I blame the community. The transition was slow (Python 2 was supported in parallel to 3 for a long period of time so there was more than enough time to migrate), relatively easy to do, and brought huge benefits to the ecosystem. It could have been done and forgotten in 2 years if some community members had not been dicks about it.

Most of the breaking changes did not justify upgrading.
Post reply on HN