Hacker News new | ask | show | jobs
by hathawsh 605 days ago
I have often thought that programmers can actually just choose to make Rust easy by using a cyclic garbage collector such as Samsara. [1] If cyclic GC in Rust works as well as I think it can, it should be the best option for the majority of high level projects that need fast development with a trade-off of slightly lower efficiency. I suspect we'll see a "hockey stick" adoption curve once everyone figures this out.

[1] https://github.com/chc4/samsara

2 comments

I am still waiting for a scripting language to be bolted on top of Rust. Something that will silently Box all the values so the programmer does not have to think about the Rust specifics, but can still lean on all of the Rust machinery and libraries. If performance/correctness becomes a problem, the scripting layer could be replaced piecemeal with real Rust.
Perhaps you mean to say that you're waiting for a new scripting language to be created that's designed to be "almost Rust." That could be interesting! OTOH, the bindings for existing languages have matured significantly:

  - https://pyo3.rs/
  - https://github.com/neon-bindings/neon
  - https://github.com/mre/rust-language-bindings
I definitely am thinking of something more Rust-forward. As Rusty as possible without having to worry about lifetimes, the borrow checker, whatever. Huge performance hit is acceptable, so long as it remains trivial to intermix the Rust+scripting code. Something that gives a smooth on-ramp to push the heavy bits into pure Rust if required. The Python+C strategy in a more integrated package.
> As Rusty as possible without having to worry about lifetimes, the borrow checker

It's Ocaml

You're very much describing the powershell -> .Net -> C# path so would be curious to hear your take there. There's also the mad lad support rust in .net https://github.com/FractalFir/rustc_codegen_clr/
And then we would’ve come full circle.

Beautiful

The world is mad. After a decade of this, I give up. The cycles never end.
I know. We're all just rediscovering Lisp in our own way.

... And yet the fact that most of us know we're reinventing Lisp, and still doing it anyway, says something. I guess it says that we're just trying to get our jobs done.

The issue with lisp is that linked lists kind of suck on modern hardware.
Lisp is a language family, not one specific language. Do you have a particular one in mind? There are many languages that can be called Lisp which are different from each other, and some have multiple implementations.

Mainstream Lisp dialects have had objects other than lists for many, many decades. The LISP-1 programmer's manual from 1960, referencing the original language which started it all, describes zero-based arrays already.

In some Lisp-like languages, the syntax processing itself is based on arrays, like Janet. The parenthesized notation turns into a nested array, not a nested linked list.

In Lisps where the syntax is based on lists, that doesn't imply that your program has to work with list at run-time. The code-transformations (macros) which happen at compile time will be working with linked lists.

Budding computer scientists and engineers like to write toy Lisp dialects (sometimes in one weekend). Often, those languages only work with linked lists, and are interpreted, meaning that the linked lists representing the code structure are traversed to execute the program, and repeatedly traversed in the case of loops.

(If you're making remarks about an important historic language family based on familiarity with someone's toy Lisp project on github, or even some dialect with an immature implementation, that is a gross intellectual mistake. You wouldn't do that, would you?)

Linked lists may "kind of suck" on cached hardware with prefetch, but that doesn't prevent them from being widely used in kernels, system libraries, utilities, language run-times (internally, even in the run-times of languages not known for exposing linked lists to the programmer), ... C programmers use linked lists like they are going out of style.

This is what async/await rust programmers need

They are comfortable with runtimes