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

301–310 of 319 posts

Re: A Rust shaped hole

#301

Post by pron »

ignoramous wrote: post #87
pron wrote: post #42

> And the very point of writing a native program in the first place is to make it feel solid. What does that mean, and what is it about native programs (i.e. programs AOT-compiled to machine code) that makes them feel solid? BTW, such programs are often more, not less, sensitive to OS changes. > realizing that I was just spawning complexity that is unrelated to the problem at hand Wait till you use Rust for a while,…

> What does that mean, and what is it about native programs (i.e. programs AOT-compiled to machine code) that makes them feel solid? BTW, such programs are often more, not less, sensitive to OS changes TFA also concludes Since I want native code ... I think by "solid" they mean as close to metal as possible, because, as you suggest, one can go "native" with AOT. With JS/TS (languages TFA prefers), I'm not sure how fa…

> I think by "solid" they mean as close to metal as possible

A JIT compiler compiles your code to machine code just as an AOT compiler does, so I don't think that's what's meant here (and they don't mean the level of the source code because they consider Haskell to be "native").

Re: A Rust shaped hole

#302

Post by willtemperley »

steveklabnik wrote: post #289
willtemperley wrote: post #282

Earlier quoted context omitted.

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

Which shows that Rust devs care very little for ergonomics.

Re: A Rust shaped hole

#303

Post by wk_end »

abhijat wrote: post #263
wk_end wrote: post #18

Earlier quoted context omitted.

I'd love to see someone develop a compiler for TypeScript that got, say, Ocaml-like performance. There's a bunch of reasons why that'd be tough though - you'd probably want a language very-similar-to-but-not-quite-like-TypeScript.

There used to be reasonml but I'm not sure how active it is these days.

ReasonML is just OCaml with a different syntax. It sort of very loosely resembles JS syntactically in that it's got curly braces, but that's about as far as the similarities go - about as much as Rust resembles C. The type system and language are very different from TypeScript or JS, and much more rigid.

Re: A Rust shaped hole

#304

Post by steveklabnik »

willtemperley wrote: post #302
steveklabnik wrote: post #289

Earlier quoted context omitted.

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

Which shows that Rust devs care very little for ergonomics.

Depending on how you define “ergonomics,” I guess. I think only needing to provide a comparison function is pretty elegant, rather than duplicating the data structure. YMMV.

Re: A Rust shaped hole

#305

Post by steveklabnik »

blub wrote: post #298
steveklabnik wrote: post #281

Earlier quoted context omitted.

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.

It’s not even close to as formal as the C++ specification because only one of them is an ISO standard, or more generally, an international standard. US corporations have massive influence over Rust since they bought seats on the board. Speaking of the board, it seems to me it’s all US based. The company working on the official spec is a Berlin LLC .

International standards have nothing to do with formality in the computer science sense.

US corporations also have massive influence on the C and C++ specifications, just look at the brouhaha around Bloomberg and contracts for C++, for example.

And the Rust Foundation does not author the specification, the Rust Project does. So in many ways, companies on the Foundation board have less direct influence than the companies who send their employees as representative to WG21 or similar.

Re: A Rust shaped hole

#306

Post by lmm »

jimbokun wrote: post #290
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?

Yes, but not garbage collection. Given that OP's main concern with Rust is not wanting to manually manage memory, they should really just use Ocaml.

Re: A Rust shaped hole

#307

Post by mikojan »

renewiltord wrote: post #91
genshii wrote: post #8

This hits close to home. TypeScript is also my language of choice for 90% of the software I write. I agree with the author that TypeScript is very close to the perfect level of abstraction, and I haven't seen another language with a type system that's nearly as enjoyable to use. Of course, TS (any by extension JS) obviously has its issues/complications. Bun solves a lot of the runtime-related issues/annoyances though…

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…

You don't have to suppress it, you just write `void` in front of the floating promise.

Which is arguably the correct way to handle this situation anyway. It makes it unmistakably clear that you are intentionally throwing away a return value.

Re: A Rust shaped hole

#308

Post by saagarjha »

freeone3000 wrote: post #258
saagarjha wrote: post #180

Earlier quoted context omitted.

You should be able to get stack traces in the debugger, what issues did you run into?

I think the issue was an async boundary - I was able to trace back to CoreFoundationLibrary but the trail ended there. Also, lldb was unable to get locals? Which is something I’ve not seen happen…

Were you inside the library itself, perhaps?

Re: A Rust shaped hole

#309

Post by Expurple »

pjmlp wrote: post #287
adastra22 wrote: post #256

Earlier quoted context omitted.

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…

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

You have gotten it across just fine.

We're trying to get across that no one is ever going to do "global" incompatible semantic changes in editions. That's been understood from the start. Exactly because of the problems that you describe.

Although, it's still possible to "sneak in" surprisingly useful semantic changes if they are local to the function body: https://doc.rust-lang.org/stable/edition-guide/rust-2024/tem...

Re: A Rust shaped hole

#310

Post by Ygg2 »

pjmlp wrote: post #196
Ygg2 wrote: post #194

Earlier quoted context omitted.

> Also the borrow checker is the Rust version of Haskell burrito blogs with monads, it is hard to get how to design with it in mind, Eh. Haskell monads are a math-centric way of performing operations on wrapped types (stuff inside a monad). Rust borrow checker is way more pragmatic-centric, i.e. how can we prevent certain behaviors. The difference being you don't see Monads being replaced by Tree-Monads, without impa…

In a way you're right, hence my last sentence.

I don't quite get what you mean by:

> Naturally those of us with experience in compilers, type systems theory and such, see it differently, we are at another level of understanding.

I mean yeah, you might have a new perspective, but so can it be a blinder to how people learn language. Curse of knowledge, and all that.

Post reply on HN