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

221–230 of 319 posts

Re: A Rust shaped hole

#221

Post by sealeck »

tayo42 wrote: post #150
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)

Does ocaml have a mature ecosystem of libraries and dependencies? And easy way to manage them? Even rust with all its hype lacks in this area imo.

It doesn't have a great ecosystem of libraries, but it _does_ have a good way to manage them: https://dune.build/, which as I understand it was developed at Jane Street (lots of code and dependencies) and is now open source.

> Even rust with all its hype lacks in this area imo.

This is surprising to me! I find that Rust has pretty excellent tooling, and Cargo is substantially better than the package manager in most other languages...

Re: A Rust shaped hole

#222

Post by _flux »

AlotOfReading wrote: post #112
LoganDark wrote: post #103

Earlier quoted context omitted.

> it a bit too idealistic and not pragmatic enough This is an ideal programming language for certain types of people. It also gives the programming language certain properties that make it useful when provable correctness is a concern (see Ferrocene).

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.

Re: A Rust shaped hole

#223

Post by sagacity »

flohofwoe wrote: post #206
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.

> But it's not unreadable. That's just because you got used to it ;) (same as with modern C++ really, if you've used C++ long enough you become blind to its problems)

This is completely true.

"Regular" Rust and C++ is fairly readable, but a quick Google for "Higher Kinded Types in Rust" ends up with [0]:

  fn ap B>(x: &>::R, arg: &>::R) -> >::R
          where Self: Plug + Plug + Plug;
[0] https://hugopeters.me/posts/14/

Re: A Rust shaped hole

#224

Post by eMSF »

tialaramex wrote: post #154
saghm wrote: post #147

Earlier quoted context omitted.

Yes, I think it's pretty easy to be sure that this isn't where the complexity comes from when there's literally a method to do that on arrays. I'm not even sure which language you're talking about here, because you can call `.len()` in Rust or `.size()` in C++. If you're trying to remember what the language is where there's no immediately obvious straightforward way to get the length of an array, it's not Rust or C++…

This is a case of exactly the "hoarder" modality in C++ that I described. When somebody says array in C++ you think of std::array, the newer shiny C++ class which you're asked to use instead of the native array types. The native array types in C++ still exist and indeed do not provide methods like size() In Rust the arrays aren't stunted left over primitive types which weren't gifted modern features, array.len() work…

While it is true that only class types have member functions in C++, that does not mean that objects of other types demand the use of macros. C++ also supports non-member functions, and the standard library contains a fair amount of these; including `std::size` that can be used to "get" the length of an array.

(C++ arrays are different from arrays in many other programming languages, though not necessarily Rust, in that their type specifies their length, so in a way this is something you already "have" but certainly there are cases where it is convenient to "get" this information from an object.)

Re: A Rust shaped hole

#225

Post by Expurple »

pjmlp wrote: post #213
Expurple wrote: post #202

Earlier quoted context omitted.

> Not really, because the crates they depend on cannot expose APIs with semantic changes across versions. Not sure what you're talking about. Any specific examples? > Also it requires everything to be compiled with the same compiler, from source code. It's not related to editions at all. It's related to not having an implicit stable ABI. It's possible have a dynamic Rust library that exposes a repr(C) interface, comp…

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

As the other commenter responded there, your example isn't about editions at all. It's about mixing ABIs and mixing multiple versions of the language runtime. Those are entirely separate issues.

You're correct that the possible changes in editions are very limited. But editions don't hinder interoperability in any way. They are designed not to. Today, there are no interoperability problems caused by editions specifically.

> compromises will be required, specially regarding possible incompatible semantic differences across editions.

That's just an assumption in your head. 4 editions later, it still hasn't manifested in any way.

Re: A Rust shaped hole

#226

Post by Expurple »

pjmlp wrote: post #219
Expurple wrote: post #215

Earlier quoted context omitted.

You're being pedantic and trying to argue as if I misunderstand language runtimes and am speaking against language runtimes in general. That's not true. I qualified "the language runtime that's installed on that OS " from the beginning.

Like on Windows for the Universal C Runtime? I can give other non-GNU/Linux examples.

I don't have any negative experience with that one, but I remember having to manually install various versions of the Windows C++ runtimes to get an app working

Re: A Rust shaped hole

#227

Post by whytevuhuni »

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!

Rust is more closely related to C++ than C.

I want Rust, but without panics, without generics (aside for lifetimes), without traits and bounds (aside for lifetimes), without operator overloading, without methods on structs, without RAII, without iterators, etc.

Re: A Rust shaped hole

#228

Post by borkido »

whytevuhuni wrote: post #227
sealeck wrote: post #218

Earlier quoted context omitted.

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

Rust is more closely related to C++ than C. I want Rust, but without panics, without generics (aside for lifetimes), without traits and bounds (aside for lifetimes), without operator overloading, without methods on structs, without RAII, without iterators, etc.

What would the benefit be of not associating functions that operate on a struct with said struct? You would just end up with a bunch of functions that take a struct of that type as their first argument.

Re: A Rust shaped hole

#229

Post by pavlov »

PartiallyTyped wrote: post #217
pavlov wrote: post #200

> “Rust, from what I've heard, has a similar abstraction level as TypeScript, perhaps even closer to Haskell but that's good, I could do with a bit more help from the compiler. But it requires me to manage memory and lifetimes, which I think is something the compiler should do for me.” The Rust compiler does manage memory and lifetimes. It just manages them statically at compile-time. If your code can’t be guaranteed…

You can use runtime ownership structures like ref cells, arcs, etc as well.

Sure. The part that people often complain about is that they have to make these decisions, rather than having a runtime default picked for them by the language.

Re: A Rust shaped hole

#230

Post by frou_dh »

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)

It doesn't use curly-braces driven syntax, so will probably be accused of being "complex" and dismissed.
Post reply on HN