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

291–300 of 523 posts

Re: The Rust I wanted had no future

#291

Post by truculent »

EdwardDiego wrote: post #122
truculent wrote: post #60

It sounds like the Rust He Wanted has a lot of thematic similarities to Elm. Interestingly, Elm has a BDFL, and a development process that reflects that. And he’s right - there are a lot of people who really don’t like that! Overall, a really interesting article. Though I like today’s Rust, I do think I would prefer the trade-offs made by the alt-Rust outlined here. Perhaps it’s just my own personal preference, but I…

My understanding is that for the Elm BDFL, the B was dropped.

The language creator has preferred to work on the development of the language largely in private, for the last couple of years. He’s explained why he’s chosen to do this and why he thinks it is beneficial. But, understandably, some people haven’t take too well to the lack of updates.

I think whether you view that as benevolent or not (I would, because I agree with lots of de facto development standards being detrimental to language quality, but I understand that that is my opinion and not hard fact) is in the eye of the beholder.

Re: The Rust I wanted had no future

#292

Post by bscphil »

gardaani wrote: post #247
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…

Rust borrow checker and lifetimes are sometimes so frustrating. I hope that the Jakt language will evolve to the language I'd like to see: Swift without ties to Apple and Objective-C.

Apple has been pushing Swift on Linux enough that I've been checking out its progress every so often. It will probably never get entirely free of ObjC but it's a nice enough language that I'd really like to be able to use it for cross-platform desktop applications. Having a pretty robust standard library and a stable ABI (currently just on macOS) are big plusses, in my book. Having a built in REPL is icing (delicious, delicious icing).

Re: The Rust I wanted had no future

#293

Post by mjburgess »

awestroke wrote: post #272
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…

> 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

Well, I'm more-or-less describing Nim.

I imagine it has more users than just me.

My version would, of course, be Nim++

Re: The Rust I wanted had no future

#294

Post by mjburgess »

kaba0 wrote: post #284
zozbot234 wrote: post #269

Earlier quoted context omitted.

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

Lifetimes only work because they are very restrictive - the moment you can’t decide that you end up with a non-safe language.

Soundness, Completeness, Saftey -- I care about these far less than

Safe, Sound, Complete 99.999% of the time; a joy to use 100% of the time

Re: The Rust I wanted had no future

#295

Post by [deleted] »

walljm wrote: post #159
anonyfox wrote: post #155

Earlier quoted context omitted.

Nowadays I program in a mostly Microsoft world (VSCode, Github, npm, typescript, GPT, ...) and I think its quite good, so no bias here. But the "shipping a native binary straight to the server that just works" is absolutely crucial for me

.net will let you do that now. You can ship precompiled binaries with Native AOT. ( https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... )

[deleted]

Re: The Rust I wanted had no future

#296

Post by mjburgess »

duped wrote: post #268
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…

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

Split the syntax into whether it 1) emits no code (compiler-facing); 2) emits weakly-related code (eg., macros, etc.); 3) emits code close to what's written abstractly (eg., value operations); 4) emits code close to what the machine needs (eg., unsafe code) -- etc.

And you'll find about "4 languages" all mixed together.

Re: The Rust I wanted had no future

#297

Post by [deleted] »

zozbot234 wrote: post #40
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.

> To clean the mess you need to remove something Sure, but that's why Carbon and Cppfront are a thing now. These two actively remove stuff from C++. We'll probably see this happen in the Rust community as well once the newer Crab language becomes established. Then we'll have to rewrite everything in Crab, but it will probably be a lot simpler than the Rust rewrite.

[deleted]

Re: The Rust I wanted had no future

#298

Post by weinzierl »

pitaj wrote: post #260
weinzierl wrote: post #125

One thing I wished was on this list, but wasn't, is syntax. I love many syntax decisions Rust made, but I wish Rust hasn't borrowed so much syntax from C/C++. The syntax of these languages was designed under (for todays standards) weird keyboard and encoding constraints and many choices are just odd. To give you a few examples: - = instead of == for equality would have been the natural choice - := for assignment is s…

Assignment is more common than equality. Typing two identical sequential characters "==" is much easier than typing ":=" especially since on most keywords colon requires shift and equal does not. And having a two-character equality operator helps align things with "!=", ">=", "<=".

Equality is so much more common than the other relational operators that it justifies the single letter.

Re: The Rust I wanted had no future

#299

Post by imtringued »

throwaway2037 wrote: post #265
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.

Nobody complains about the Java compiler. Everyone complains about the class loading performance.

Re: The Rust I wanted had no future

#300

Post by marcosdumay »

titzer wrote: post #178

> Library-defined containers, iteration and smart pointers. Containers, iteration and indirect-access operations (along with arithmetic) comprise the inner loops of most programs and so optimizing their performance is fairly paramount; if you make them all do slow dispatch through user code the language will never go fast. If user code is involved at all, then, it has to be inlined aggressively. The other option, whi…

Almost all high-level languages have builtin containers. I do think it's a bad fit for Rust (at least for what Rust became), but it's not the end of the world by itself.

The fact that JS has about 3 of them (is it only 3? I'm not sure of this), with different interfaces, and non-usual behavior is what creates problem there. But other languages quite successfully make their own containers either different enough or similar enough that it's not a problem.

Post reply on HN