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

A Rust shaped hole

mnvr.in

Post reply on HN
Print view View original

281–290 of 319 posts

Re: A Rust shaped hole

#281

Post by steveklabnik »

tines wrote: post #252
Expurple wrote: post #211

Earlier quoted context omitted.

Rust doesn't need a formal document so badly, because (in safe code) the punishment for not following the rules is much more clear and small. It's either a logic bug that doesn't lead to memory-related vulnerabilities, or a readable compiler error. Of course, if your compiler doesn't catch and explain your errors to you, you need a separate book to help you with that!

To be fair, the formal document isn't for language users, it's for compiler implementors. Rust doesn't have a formal document for other reasons, mainly that there is one main Rust compiler, as opposed to C or C++ where there are dozens that all need to agree on behavior.

People over-index on "formal" here, the Rust reference and Ferrocene (which will end up being adopted as the official spec) is just as "formal" as the C++ specification.

There are other compilers in development, and they're able to coordinate with these documents. There is of course always more work to do, but it's really not as far away as some people believe.

Re: A Rust shaped hole

#282

Post by willtemperley »

cosmic_cheese wrote: post #71
_mlbt wrote: post #35

Earlier quoted context omitted.

Swift is a great C++ and Rust alternative that doesn’t get enough attention outside of Apple platforms. It’s a performant, statically typed, compiled language that feels almost like a scripting language to write code in. It’s memory safe, cross platform, has a fantastic standard library, and has excellent concurrency capabilities. Even the non-Xcode tooling is maturing rapidly. The big weak spot really is lack of com…

I would love to see a cross-platform desktop UI toolkit for Swift, preferably one that’s reactive and imperative-dominant with declaritivity sprinkled in where it makes sense (all-in declarative design like SwiftUI hits too many language weak points for the time being). Swift is really quite nice to write once you get a feel for it, and as long as one is judicious about advanced feature use, it looks more familiar an…

Swift is coming to Android. That may improve traction. [1]

Having just ported a small library from Rust to Swift, it’s fairly clear that Rust is ridiculously fast but Swift is just so much more readable. Much easier to debug too.

Also - why would Rust only have a max-heap? In the library I ported, the authors had to reverse the algorithmic logic in the entire library for this.

Even though it’s only about half as fast as Rust, Swift performance does start to shine with concurrency.

[1] https://www.swift.org/android-workgroup/

Re: A Rust shaped hole

#283

Post by dxxvi »

whytevuhuni wrote: post #144
Expurple wrote: post #41

> If someone posts a patch or submits a PR to a codebase written in C, it is easier to review than any other mainstream language. There is no spooky at a distance. [..] Changes are local. Lol, wut? What about about race conditions, null pointers indirectly propagated into functions that don't expect null, aliased pointers indirectly propagated into `restrict` functions, and the other non-local UB causes? Sadly, C's e…

If anything I'd like an even lower-level Rust. There's so many good high-level languages to choose from, but when you need to go low-level, there's essentially only C, C++, Rust. Maybe Zig once it reaches 1.0. What we need isn't Rust without the borrow checker. It's C with a borrow checker, and without all the usual footguns.

> What we need isn't Rust without the borrow checker. It's C with a borrow checker, and without all the usual footguns

I agree with the other comment. Then what you need is Rust without all the bells and whistles (pattern matching, Cow, Rc, Result, Option ...).

Re: A Rust shaped hole

#284

Post by chainwax »

shim__ wrote: post #201
skybrian wrote: post #125

Earlier quoted context omitted.

You can’t? I haven’t used it, but what’s wrong with “deno compile?” https://docs.deno.com/runtime/reference/cli/compile/

Sounds like electron but for cli

I does indeed bundle it's runtime into the executable, but this is not dissimilar from Go bundling it's gc into every executable.

Granted a compiled hello world Go program will be <2mb while a similar compiled Deno program will be more like 70. I imagine many usecases may not have a storage constraint though, and in that case why not?

Re: A Rust shaped hole

#285

Post by renewiltord »

WorldMaker wrote: post #271
renewiltord wrote: post #91

Earlier quoted context omitted.

I recently came to a production Typescript codebase and it took minutes to compile. Strangely, it could not behave correctly without a linter rule `no-floating-promises` but the linter also took minutes to lint the codebase. It was an astounding exercise in patience. Faster linters like oxlint exist but they don't have a notion of cross-file types so `no-floating-promises` is impossible on them. The worst part is tha…

Promise is not T and Typescript's type system will catch that in most cases with a simple type assertion (add a type to the function return; add a `satisfies` check somewhere). If it isn't catching it often enough, without a lot more extra type assertions, you may be missing a Typescript strict flag like noImplicitAny. (In general I find that I prefer the full `"strict": true` in the compilerOptions of tsconfig.json…

Yeah, the codebase in question was using an “insert into db but do not check result and let exceptions inform” pattern. It was probably transformed from JS at some point which is why it used Knex I must guess.

So I suppose I should have found some condition to force use of return values and then unleashed Claude code to fix up linting errors.

It’s rarely a GetX resulting in a Promise that’s mismatched and more an insertX followed by an insertY on the same transaction without awaiting the first insertX that’s the problem. Makes it a heisenbug.

I wouldn’t mind it if the linter was oxlint speed but eslint was a 5 minute affair on the codebase. It’s sort of a Moravec’s Paradox of its own: web development is much more complex than the HFT strats we deployed (which could compile and sim something faster than this can lint).

I suppose I can’t blame the query builder on the tool choice but they were pretty stuck on Knex by then.

Your advice is appreciated. Thank you.

Re: A Rust shaped hole

#286

Post by pjmlp »

Expurple wrote: post #254
pjmlp wrote: post #247

Earlier quoted context omitted.

In any case, while I as language geek have these kind of discussions, given current progress in AI systems, my point of view is that we will get the next evolution in programming systems, thus it won't matter much if it is C, C++, Rust, C#, Java, Go or whatever. We (as in the industry) will eventually get reliable ways to generate applications directly to machine code, just as optimizing compilers took a couple of de…

The machine code will always be generated from "something". A one-line informal prompt isn't enough. There will always be people who write specs. Even the current languages are already far from "machine code" and could be considered "specs", albeit low-level

Indeed, I never said it was a bare bones prompt.

Re: A Rust shaped hole

#287

Post by pjmlp »

adastra22 wrote: post #256
pjmlp wrote: post #213

Earlier quoted context omitted.

To avoid repeating myself, here is an example from 4 years ago. https://news.ycombinator.com/item?id=26966151

As the response to that comment points out, you are confusing editions for ABI changes. Different editions are purely a source-level change in the language. All editions are ABI-compatible.

Not really, because one thing that apparently I haven't gotten across is that they don't cover semantic changes, only grammar ones for the most part.

What is the compiler supposed to generate if code from edition X calls code in edition X + 10, with a lambda written in X + 5, expecting using a specific language construct that has changed semantics across editions, maybe even more than once?

Everything compiling from source, same compiler.

Re: A Rust shaped hole

#288

Post by jimbokun »

fn-mote wrote: post #136
bryanlarsen wrote: post #86

Earlier quoted context omitted.

Reading between the lines, the author is a Haskell fan. Haskell is another "complicated" language, but the complexity feels much different than the C++ complexity. Perhaps I would describe it as "complexity that improves expressiveness". If you like Haskell for its expressiveness but dislike C++ for it's complexity, I suspect Rust is a language you're going to like.

My impression was the opposite. I wondered how well the author knew Haskell. They mention: (1) The "intimidating syntax". Hey, you do not even need to be using never mind the rest of those operators. Perl and Haskell can be baroque, but stay away from that part of the language until it is useful. (2) "Changes are not localized". I'm not sure what this means. Haskell's use of functions is very similar to other languag…

> (1) The "intimidating syntax". Hey, you do not even need to be using never mind the rest of those operators. Perl and Haskell can be baroque, but stay away from that part of the language until it is useful.

But you have to be able to read and understand code using them.

Re: A Rust shaped hole

#289

Post by steveklabnik »

willtemperley wrote: post #282
cosmic_cheese wrote: post #71

Earlier quoted context omitted.

I would love to see a cross-platform desktop UI toolkit for Swift, preferably one that’s reactive and imperative-dominant with declaritivity sprinkled in where it makes sense (all-in declarative design like SwiftUI hits too many language weak points for the time being). Swift is really quite nice to write once you get a feel for it, and as long as one is judicious about advanced feature use, it looks more familiar an…

Swift is coming to Android. That may improve traction. [1] Having just ported a small library from Rust to Swift, it’s fairly clear that Rust is ridiculously fast but Swift is just so much more readable. Much easier to debug too. Also - why would Rust only have a max-heap? In the library I ported, the authors had to reverse the algorithmic logic in the entire library for this. Even though it’s only about half as fast…

> Also - why would Rust only have a max-heap? In the library I ported, the authors had to reverse the algorithmic logic in the entire library for this.

All you have to do is use a small wrapper type and you get a min heap https://doc.rust-lang.org/std/collections/struct.BinaryHeap....

Re: A Rust shaped hole

#290

Post by jimbokun »

lmm wrote: post #94

If they're serious about their criteria they should go with OCaml (or maybe, like, Swift, or any of dozens of languages in that space). (Of course they actually do want Haskell but they probably need to get there gradually)

Doesn't Rust steal a lot from Ocaml?
Post reply on HN