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

261–270 of 523 posts

Re: The Rust I wanted had no future

#261

Post by divan »

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…

It's crazy that the programming community even accepted the concept of async/await as a sane one.

Being sync or async is essentially a property of the attention of the caller, not of the action itself. Is "eating a donut" a sync or async action? If I'm focusing all my attention on it, essentially putting all tasks aside (after) - then it's a synchronous action. If I'm reading a book/watching a video/walking/etc, while eating – it's an async action.

How does "func EatADonut() async {}" aka "eating a donut is an inherently async action" even make sense to people?

Re: The Rust I wanted had no future

#262

Post by moi2388 »

kaba0 wrote: post #211
pjc50 wrote: post #145

Earlier quoted context omitted.

> Compiled vs interpreted makes it easier to catch (syntax) errors beforehand. ... Mapping JSON (or whatever) to strongly typed objects is great cough C#. You also get LINQ. And a fairly heavy amount of web frameworks in ASP.NET / Razor.

Or Java, F#, Scala, Kotlin, Haskell. If we were to randomly pick a language, chances are it could be a good fit for these — Rust became as well-known as is because it was made for a different niche, where there were no competition.

Haskell is a beautiful language, but I find their web frameworks rather cumbersome to work with personally.

Re: The Rust I wanted had no future

#263

Post by throwaway2037 »

naraga wrote: post #166
anonyfox wrote: post #152

Earlier quoted context omitted.

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 believe you can https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

I can vouch for it! I returned to C# for a tiny desktop GUI recently. I was blown away by how simple is the tooling to create a single monolithic binary. It's great for enterprise distribution. "No more installer."

Re: The Rust I wanted had no future

#264

Post by pitaj »

kaba0 wrote: post #223
LinXitoW wrote: post #141

Earlier quoted context omitted.

> Why on earth would you try to rewrite python CRUD apps in Rust? Because Rust has a lot of incredibly helpful features that make bigger systems far less of a pain to maintain. I work in Java/Kotlin, and my entirely gut-based estimate is that 66% of problems wouldn't happen in Rust. My big favorites are: - Sane, well-defined, enforced, opt-out error handling - Sane, well-defined, enforced, opt-out handling of "missin…

Scala has all of that and predates Rust by far. But even Java is pretty much there: checked exceptions are available (and imo superior), but Optional is also an.. option. Kotlin/scala can handle nulls, but java can also statically analyse every usage with annotations. switch expressions are exhaustive in java over enums and sealed ADTs. (Rust has a misnomer, their enums are ADTs, java has both real enums and ADTs now…

Rust enums cover both ADTs and enums.

Re: The Rust I wanted had no future

#265

Post by throwaway2037 »

javajosh wrote: post #162

Too bad graydon didn't get his way with build times. I've come to believe that the most important feature of any development environment is to minimize the built-test-debug cycle. Of course, a real system has many different ones, ranging from "language level" to "I have to redeploy and perform a complex series of actions in an app or 3". But at the language level I've found that build performance is of paramount impo…

I'm not here to advocate for Lombok. However, you are first that I saw here to complain about much slower compile times. Can you teach me more? On a multi-core 5GHz desktop PC with 64GB RAM, who is really thinking about Java compile times these days? And I have worked on 1M+ line projects. Sure, the first compile is slow, but after, everything is incremental.

Re: The Rust I wanted had no future

#266

Post by svieira »

josephg wrote: post #76
sph wrote: post #22

Earlier quoted context omitted.

I disagree. You can call an async function in Rust from a regular one, that's true, but the returned value still needs to be passed through an executor to be useful. Async without function coloring means being able to call `async fn add(a, b: usize) -> usize` from anywhere and having an usize back, whether you're calling from a regular or async function. If you need slightly different logic because of async, you got…

Its certainly possible with compiler magic. Zig does exactly that - where functions can be colorless and they work slightly differently in async and syncronous contexts, doing the obvious thing in both cases. I'm not sure how well it works in practice (I haven't spent enough time with zig to know). I'd worry that bugs would creep in to whichever variant of the function you aren't exercising. Its a lovely design thoug…

_Unyielding_ describes the issues that arise when the author of the code doesn't have control of the transactionality / atomicity of their operations at the level they need to: https://glyph.twistedmatrix.com/2014/02/unyielding.html

To my mind it's very much a balancing act between "low power to the developer, high power to the language" and "high power to the developer, low power to the language" all up and down the stack from software / hardware to "consumer / framework".

Re: The Rust I wanted had no future

#267

Post by iMerNibor »

bluGill wrote: post #189
twic wrote: post #121

Earlier quoted context omitted.

> Anyone writing these things today in C or C++ already understands object lifetimes and Rust just adds a static checker for them. I've certainly seen seasoned C++ programmers saying this. Of course, a few of them of say they understand object lifetimes so well, they they don't need the static checker! > Why on earth would you try to rewrite python CRUD apps in Rust? This is one of the great mysteries of our times. I…

> Of course, a few of them of say they understand object lifetimes so well, they they don't need the static checker! There is a difference between understanding lifetimes and being able to keep track of them. I have a lot of objects in my more than 10 million lines of code. Most of them have simple lifetimes that are easy to track, but a few for reasons (which may or may not be valid - often the reasons are it was bu…

Being able to stop constantly keeping things in the back of your head and just trusting the compiler to complain if something is off was the biggest differentiator for me by far. Less footguns = more better

Re: The Rust I wanted had no future

#268

Post by duped »

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…

> This "two syntaxes, one for the runtime and one for the compiler" approach -- has swamped Rust as it aims for greater expressiveness. Not least, because it has a third syntax: one for unsafe.

What are you referencing, concretely? For example, "unsafe" doesn't add or remove syntax.

Re: The Rust I wanted had no future

#269

Post by zozbot234 »

kaba0 wrote: post #234
mjburgess wrote: post #230

Earlier quoted context omitted.

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).

It's undecidable in the general case, but it becomes doable in non-Turing-complete languages that are still expressive enough to be useful for many practical cases. (These languages can express unrestricted recursion as an I/O-like effect that's only available outside the language proper, as part of compiling to a binary.)
Post reply on HN