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

231–240 of 523 posts

Re: The Rust I wanted had no future

#231

Post by LeanderK »

tijsvd wrote: post #50
LeanderK wrote: post #39

Can someone comment on "Library-defined containers, iteration and smart pointers"? I have no rust experience so far. Magic compiler support for such primitives is something I usually very much, really strongly dislike, it was always my experience that it is the wrong point of abstraction because it just reduces the design state so much. But then you need good support for inlining the relevant parts of the language, w…

Everything that's visible to the compiler is subject to automatic inlining. That is all code in the current crate (compilation unit), all concrete instantiations of generics (regardless where defined), and all functions marked inline (regardless which crate). Stdlib containers are all in the generics category.

> all functions marked inline (regardless which crate).

Is this a problem is rust? Is too much/too little marked inline? What if you really need to inline some function from some library that was not marked inline by the author?

Re: The Rust I wanted had no future

#232

Post by ontologiae »

anonyfox wrote: post #152
FrustratedMonky wrote: post #148

Earlier quoted context omitted.

I would like to second F#. It seems to have a lot of what people want, so why isn't it more popular?

Can I natively build self-contained binaries? One of Go's biggest advantages is the delivery chain from code to server (build for target arch, copy to target, ./run)?

I had to deal with it, when I hadto parse Transac-SQL code, and it's not handy. Very difficult to have a single executable file containing everything, it needs a whole subtree. OCaml is easier with Opam and ocamlbuild tools.

Re: The Rust I wanted had no future

#233

Post by pmontra »

layer8 wrote: post #82
Aardwolf wrote: post #77

> Tail calls. I actually wanted them! I think they're great. And I got argued into not having them because the project in general got argued into the position of "compete to win with C++ on performance" and so I wound up writing a sad post rejecting them I don't understand the subtleties here: Is tail calls an optimization the compiler can do irrespective of the language? Or is there something that prevents this and…

It’s about stack size. Programs that rely on tail calls (in particular recursive ones) may cause the stack to overflow when the language implementation doesn’t actually support tail calls, for example when using tail calls to recursively process a list that is larger than (some constant fraction of) the stack. With an infinite stack, it would just be an optimization, but in practice the stack is finite (and significa…

That's why we write programs that rely on tail calls only for languages that have TCO in their specification. Where TCO is idiomatic (e.g. Elixir) implementations not supporting it are impossible because they will be able to run only the simplest programs.

The problem is adding TCO to a language that was born without it. It won't break existing programs but you'll be able to run a program using TCO only with a specific compiler or interpreter from a given version. It could catch up if the main implementation of the language does it, but often we care about compatibility with the alternative implementations. Think about Ruby and Python, MRI and CPython and all the other implementations of the language. If I'm not wrong, MRI added TCO under a runtime configuration variable but JRuby doesn't support it.

Re: The Rust I wanted had no future

#234

Post by kaba0 »

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…

You quickly gets into the undecidable category once you to down that road, which might be fine if you either don’t care about safety, or have runtime checks for that, but none of those were an option for rust (or at least an option that would have made it remotely interesting).

Re: The Rust I wanted had no future

#235

Post by School-Cotton »

hgomersall wrote: post #220
School-Cotton wrote: post #182

Earlier quoted context omitted.

They could have simply not added async to the language. I was happily using rust before async and it was perfectly fine.

So don't use it. Why object to those that do have a use case for it?

Because I have to work with other people (both coworkers and developers of library crates).

Re: The Rust I wanted had no future

#236

Post by anonyfox »

amelius wrote: post #196
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…

OCaml?

really tried to get into it for a while, but the tooling situation feels like the polar opposite of Go, where everything needed in daily work is right there in a standardized way and just works out of the box.

I kinda like the language (its what I want basically) but the operational aspects are what I actually need and want first and foremost.

Re: The Rust I wanted had no future

#237

Post by dmm »

pjmlp wrote: post #226
Ygg2 wrote: post #17

Earlier quoted context omitted.

Performance, but with sanity. Say you use a vector in C++. You push one element and pop two. In Rust that's a None. In C++ the answer is UB (in my case 43).

In C++ it is an error, if one bothers to enable bounds checking. https://godbolt.org/z/vYcMhE9h7 > Error: attempt to access an element in an empty container.

Someone much more insightful than me pointed out that most of the safety advantages of Rust are really a cultural phenomenon, rather than a strictly technical one. You could write unsafe unsafe Rust that derefs invalid pointers all day but when building systems and libraries with Rust, people value safety and Rust enables that as a priority.

Re: The Rust I wanted had no future

#238

Post by scns »

Merad wrote: post #215
inferiorhuman wrote: post #100

Earlier quoted context omitted.

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.

Your knowledge of the .Net ecosystem is a bit out of date. It's had first class support for mac and linux for 7-8 years now.

First class support on Linux and Mac with caveats. Zero snark intended.

Re: The Rust I wanted had no future

#239

Post by moth-fuzz »

pornel wrote: post #18
sph wrote: post #6

Very interesting insight from Graydon, in hindsight I too would have loved something more towards ML than C++. I never liked the kitchen sink approach that I see first C++, now Rust moving towards, but I respect what Rust has managed to solidify into. It's a good language. That said, I still hate async with a passion, it makes the language more complex and not very elegant (i.e. function coloring). And now that I kno…

Function coloring article conflated two things: one was legitimate limitation of JS unable to wait for async result from sync call, and the other was just author's opinion how the syntax should look like. Rust's async doesn't have the limitation author described – you can spawn and block both (Tokio has some limits there, but that's Tokyo's choice, not language limitation), making "color" largely irrelevant. The seco…

You can't evaluate a future in normal rust as there's no default executor, you need to pull in some library to even make blocking calls to async functions.

IMO, this is even worse than function coloring.

Re: The Rust I wanted had no future

#240

Post by ay »

hgomersall wrote: post #220
School-Cotton wrote: post #182

Earlier quoted context omitted.

They could have simply not added async to the language. I was happily using rust before async and it was perfectly fine.

So don't use it. Why object to those that do have a use case for it?

fragmentation of the library ecosystem.
Post reply on HN