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

91–100 of 319 posts

Re: A Rust shaped hole

#91

Post by renewiltord »

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 that `no-floating-promises` is strange. Without it, Knex (some ORM toolkit in this codebase) can crash (segfault equivalent) the entire runtime on a codebase that compiles. With it, Knex's query builders will fail the lint.

It was confusing. The type system was sophisticated enough that I could generate a CamelCaseToSnakeCase type but somehow too weak to ensure object borrow semantics. Programmers on the codebase would frequently forget to use `await` on something causing a later hidden crash until I added the `no-floating-promises` lint, at which point they had to suppress it on all their query builders.

One could argue that they should just have been writing SQL queries and I did, but it didn't take. So the entire experience was fairly nightmarish.

Re: A Rust shaped hole

#92

Post by nemothekid »

uecker wrote: post #69
Expurple wrote: post #67

Earlier quoted context omitted.

> A line of code does not depend on a million other things. But it does! To qoute my top-level comment: > 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? In other words: you set some pointer to NULL, this is OK in that part of your program, but then the valu…

This is true to some degree, but not really that much in practice. When refactoring you just add assertions for NULL (and the effect of derefencing a NULL in practice is a trap - that it UB in the spec is completely irrelevant. in fact it helps because it allows compilers to turn it a trap without requiring it on weak platforms). Restrict is certainly dangerous, but also rarely used and a clear warning sign, compare…

>When refactoring you just add assertions for NULL

This is a line of thinking I used to see commonly when dynamic typing was all the rage. I think the difference comes from people who view primarily work on projects where they are the sole engineer vs ones where they work n+1 other engineers.

"just add assertions" only works if you can also sit on the shoulder of everyone else who is touching the code, otherwise all it takes is for someone to come back from vacation, missing the refactor, to push some code that causes a NULL pointer dereference in an esoteric branch in a month. I'd rather the compiler just catch it.

Furthermore, expressive type systems are about communcation. The contracts between functions. Your CPU doesn't case about types - types are for humans. IMO you have simply moved the complexity from the language into my brain.

Re: A Rust shaped hole

#93

Post by andrepd »

uecker wrote: post #20

It is a bit unclear to me why somebody who rejects C++ because "I once spent an entire year in the heaven of C++, walking around in a glorious daze of std::vector and RAII, before one day snapping out of it and realizing that I was just spawning complexity that is unrelated to the problem at hand." (which I can absolutely agree with!) is picking Rust from all options. If there is a language that can rival C++ in term…

It's really not even remotely the same. C++ has literally >50 pages of specification on the topic of initialising values. All of these are inconsistent, not subject to any overarching or unifying rule, and you have to keep it all in mind to not run into bugs or problematic performance.

Rust is a dead simple language in comparison.

Re: A Rust shaped hole

#94

Post by lmm »

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)

Re: A Rust shaped hole

#95

Post by Dylan16807 »

bryanlarsen wrote: post #89
uecker wrote: post #45

Earlier quoted context omitted.

I do not really agree with respect to C. I often have to deal with C code written by unexperienced programmers. It is always relatively easy to refactor it step by step. For C++ this is much more painful because all the tools invented to make the code look concise make it extremely hard to follow and change. From the feature set, I would say that Rust is the same (but I have no experience refactoring Rust code).

> but I have no experience refactoring Rust code But you're willing to write many comments complaining that Rust is hard to refactor. Rust is the easiest language to refactor with I've ever worked in, and I've used a couple dozen or so. When you want to change something, you change it, and then fix compiler errors until it stops complaining. Then you run it, and it works the first time you run it. It's an incredible…

> But you're willing to write many comments complaining that Rust is hard to refactor.

Their refactoring comments look focused on C versus C++ to me, with a bit of guessing Rust is like C++ in a way that is clearly labeled as speculation.

So I don't see the problem with anything they said about refactoring.

Re: A Rust shaped hole

#96

Post by zem »

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)

right! the table at the end just screamed "use ocaml and be happy"

Re: A Rust shaped hole

#97

Post by legobmw99 »

zem wrote: post #96
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)

right! the table at the end just screamed "use ocaml and be happy"

nobody gives OCaml a thought in these discussions. It’s such a wonderful language!

Re: A Rust shaped hole

#98

Post by bsder »

bryanlarsen wrote: post #89
uecker wrote: post #45

Earlier quoted context omitted.

I do not really agree with respect to C. I often have to deal with C code written by unexperienced programmers. It is always relatively easy to refactor it step by step. For C++ this is much more painful because all the tools invented to make the code look concise make it extremely hard to follow and change. From the feature set, I would say that Rust is the same (but I have no experience refactoring Rust code).

> but I have no experience refactoring Rust code But you're willing to write many comments complaining that Rust is hard to refactor. Rust is the easiest language to refactor with I've ever worked in, and I've used a couple dozen or so. When you want to change something, you change it, and then fix compiler errors until it stops complaining. Then you run it, and it works the first time you run it. It's an incredible…

> Rust is the easiest language to refactor with I've ever worked in

Oh? So how do you refactor a closure into a named function in Rust?

I have found this to be of the most common failure modes that makes people want to punch the monitor.

(Context: in almost all programming languages, a closure is practically equivalent to an unnamed function--refactoring a closure to a named function tends to be pretty straightforward. This isn't true for Rust--closures pick up variable lifetime information that can be excruciatingly difficult to unwind to a named function.)

Re: A Rust shaped hole

#99

Post by TOGoS »

I'm interested in the long piecewise elimination section. Presumably that's where they explain why not use Ocaml/Nim/yaddah yaddah.

If I were to write such a list, the answer would probably come down to "because I wanted to pick ONE and be able to stick with it, and Rust seems solid and not going anywhere." As much as Clojure and Ocaml are, from what I've heard, right up my alley, learning all these different languages has definitely taken time away from getting crap done, like I used to be able to do perfectly well with Java 2 or PHP 5, even though those are horrible languages.

Re: A Rust shaped hole

#100

Post by bryanlarsen »

bsder wrote: post #98
bryanlarsen wrote: post #89

Earlier quoted context omitted.

> but I have no experience refactoring Rust code But you're willing to write many comments complaining that Rust is hard to refactor. Rust is the easiest language to refactor with I've ever worked in, and I've used a couple dozen or so. When you want to change something, you change it, and then fix compiler errors until it stops complaining. Then you run it, and it works the first time you run it. It's an incredible…

> Rust is the easiest language to refactor with I've ever worked in Oh? So how do you refactor a closure into a named function in Rust? I have found this to be of the most common failure modes that makes people want to punch the monitor. (Context: in almost all programming languages, a closure is practically equivalent to an unnamed function--refactoring a closure to a named function tends to be pretty straightforwar…

Set the type of all the parameters to your new function to bool, then compile. The compiler error will tell you, "Error: you passed a foo instead of a bool". Then you change the type in the function's parameter to "foo".
Post reply on HN