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

271–280 of 319 posts

Re: A Rust shaped hole

#271

Post by WorldMaker »

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…

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 and always write for all strict checks.)

Also if your codebase is still relying on "explicit" `any`, try `unknown`.

Also, yeah Knex doesn't look like the best ORM for a Typescript codebase. Typescript support in Knex is clearly an after thought, and the documentation admits it:

> However it is to be noted that TypeScript support is currently best-effort.

Re: A Rust shaped hole

#272

Post by liampulles »

selfmodruntime wrote: post #4

I write Gleam for this. A rust like language on the erlang VM. It's neat, but not widely used.

I've written some Gleam as an exploration, and I liked it, but the "not widely used" thing is a concern. I need there to be some well maintained libraries for enterprise stuff.

I know this is not the fault of the language, and that is unfortunate.

Re: A Rust shaped hole

#273

Post by shmerl »

throwawaymaths wrote: post #268
shmerl wrote: post #141

Earlier quoted context omitted.

Syntax could be less terse and abbreviated, I agree. But it's not unreadable. On the other hand some complain that Rust sometimes is too verbose, so I guess it's some balance.

verbosity is not really the same as nonreadability. i would say the biggest factor for nonreadability is not being able to chase function calls using simple text search, with as few indirections as possible. proc macros and to a lesser degree traits make that difficult.

Yeah. You can to use LSP to work around it for usage search (which is really helpful), but it's definitely not a human readable case if function name is obscured.

Re: A Rust shaped hole

#274

Post by mrkeen »

Sophistifunk wrote: post #108
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 very much enjoy reading and writing TS code. What I don't enjoy is the npm ecosystem (and accompanying mindset), and what I can't stand is trying to configure the damn thing. I've been doing this since TSC was first released, and just the other day I wasted hours trying to make a simple ts-node command line program work with file-extension-free imports and no weird disagreements between the ts-node runner and the l…

I encountered this trying out PureScript. Looks like a good language, but I gave up after a couple of trips through npm, bower, yarn...

Re: A Rust shaped hole

#275

Post by liampulles »

I like the "lower level of abstraction" of Go. It was a transition coming from writing Spring Boot Java code to having to actually implement the "magic", but I like that I can clearly see the control flow of things in Go.

Out of all the languages I've used, Go programs are the ones that have the highest percentage chance of working "first try". I think that has a lot to do with the plain and strongly typed style.

Re: A Rust shaped hole

#276

Post by Xunjin »

pjmlp wrote: post #176
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…

The C myth keeps being perpetuated, sadly. And had not GNU/FSF made C the official main language for FOSS software on their manifesto, by the time when C++ was already the main userspace language across Windows, OS/2, Mac OS, BeOS, that "It is the reason for C's endurance" would be much less than it already is nowadays, where it is mostly UNIX/POSIX, embedded and some OS ABIs.

It's funny because that was the main argument against Rust when I introduced it at the company I worked for before, but the tool has been widely used internally ever since. Because made it easy to understand the locality PRs and how it solved most safety issues (they still need some unsafe usage).

Re: A Rust shaped hole

#277

Post by trealira »

buzzin__ wrote: post #251
whytevuhuni wrote: post #144

Earlier quoted context omitted.

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.

"C is the language that combines raw power of assembly with expressiveness of assembly."

> "C is the language that combines raw power of assembly with expressiveness of assembly."

The most expressive part of C is the syntax oriented around writing terse, side-effectful expressions that manipulate buffers, pointers and counters, with the array of precedences and the pre- and post-increments and assignment operators and short-circuiting operators. You can write stuff like this:

  while (--n > 0 && (c = getchar()) != EOF && (*s++ = c) != '\n')
      ;
  *s = '\0';
Or these snippets (taken from K&R):

  // Parsing flags for command line arguments
  while (--argc > 0 && (*++argv)[O] == '-')
      while (c = *++argv[O])
          switch (c) {
          // ...
          }

  // Last line of a buffered `getchar()` implementation 
  return (--n >= 0) ? (unsigned char) *bufp++ : EOF;
You can write other programs in C, like GUI programs and compilers, but it's not as nearly tailor made for such programs and it's basically just like assembly, like you said.

Re: A Rust shaped hole

#278

Post by mrkeen »

klntsky wrote: post #27
slowcache wrote: post #15

Odin has been really growing on me lately as a language that checks all of those boxes. String types, first class allocators, built in tests, a batteries included philosophy, and ease of use are some of the things that really drew me towards it. I really wanted to like rust and I wrote a few different small toy projects in it. At some point knowledge of the language becomes a blocker rather than knowledge the problem…

What's the difference between anti-DIY and "batteries included"?

Batteries included is a fat, opinionated standard library.

I think for some devs, if you import from the standard library, that somehow counts as DIY, whereas if you import from libraries that aren't distributed with the compiler, it's anti-DIY.

Re: A Rust shaped hole

#279

Post by DeepSeaTortoise »

sealeck wrote: post #218
whytevuhuni wrote: post #144

Earlier quoted context omitted.

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. Which would look a lot like... Rust!

I disagree. I like playing around in Rust, but it is near impossible to reason about what instructions will end up being fed to your CPU without having the compiler emit the underlying assembly.

And that makes it very difficult to understand the performance of your code. Just a few days ago I couldn't wrestle the compiler into unrolling a loop (because of a get_unchecked that was hard to reason about), dropping performance of the entire data structure to as little as 30% of a quick proof of concept implementation. The asserts are powerful tools, but only if you can figure out why the compiler is not behaving nicely and how to construct the conditions that will convince it...

Re: A Rust shaped hole

#280

Post by steveklabnik »

_flux wrote: post #222
AlotOfReading wrote: post #112

Earlier quoted context omitted.

Last time I talked to the ferrocene people they had no plans to do anything with formal methods. Has their scope expanded?

Maybe it was intended to refer to RustBelt. I haven't been following their work, though. It seems they are working on stacked borrows.

> I haven't been following their work, though. It seems they are working on stacked borrows.

We're a few years past that, there's now 'tree borrows' which just had its paper published: https://www.ralfj.de/blog/2025/07/07/tree-borrows-paper.html

Post reply on HN