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

211–220 of 319 posts

Re: A Rust shaped hole

#211

Post by Expurple »

blub wrote: post #204
andrepd wrote: post #93

Earlier quoted context omitted.

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.

As the definition says, the C++ standard is a formal technical document. Rust doesn’t have a standard, it has a book, so you should refer to the initialization section from Stroustrup’s C++ book to keep things fair.

Rust doesn't need a formal document so badly, because (in safe code) the punishment for not following the rules is much more clear and small. It's either a logic bug that doesn't lead to memory-related vulnerabilities, or a readable compiler error. Of course, if your compiler doesn't catch and explain your errors to you, you need a separate book to help you with that!

Re: A Rust shaped hole

#212

Post by sesm »

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

Good luck to the author with trying Rust. I hope he writes an honest experience report.

Re: A Rust shaped hole

#213

Post by pjmlp »

Expurple wrote: post #202
pjmlp wrote: post #183

Earlier quoted context omitted.

Not really, because the crates they depend on cannot expose APIs with semantic changes across versions. Also it requires everything to be compiled with the same compiler, from source code. There are tools available in some C++ compilers for migration like clang, note the difference between ISO languages with multiple implementations, and one driven by its reference compiler.

> 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

Re: A Rust shaped hole

#214

Post by childintime »

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…

Fully agree. Try bun.

Re: A Rust shaped hole

#215

Post by Expurple »

pjmlp wrote: post #207
Expurple wrote: post #203

Earlier quoted context omitted.

I meant a runtime that has to be installed separately. It's possible to statically link a C runtime if you use musl, for example

You mean like it happens on many OSes that aren't GNU/Linux? A language runtime remains one, independently on how it was linked into the binary. A language runtime are the set of operations that support the language semantics, which in C's case are everything that happens before main() , threading support (since C11), floating point emulation (if needed), execution hooks for running code before and after main() , del…

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.

Re: A Rust shaped hole

#216

Post by [deleted] »

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…

[deleted]

Re: A Rust shaped hole

#217

Post by PartiallyTyped »

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.

Re: A Rust shaped hole

#218

Post by sealeck »

whytevuhuni wrote: post #144
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…

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!

Re: A Rust shaped hole

#219

Post by pjmlp »

Expurple wrote: post #215
pjmlp wrote: post #207

Earlier quoted context omitted.

You mean like it happens on many OSes that aren't GNU/Linux? A language runtime remains one, independently on how it was linked into the binary. A language runtime are the set of operations that support the language semantics, which in C's case are everything that happens before main() , threading support (since C11), floating point emulation (if needed), execution hooks for running code before and after main() , del…

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.

Re: A Rust shaped hole

#220

Post by Expurple »

blub wrote: post #210
Expurple wrote: post #191

Earlier quoted context omitted.

Go is "straightforward" at the cost of making your codebase not straightforward: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... . Programming is complex. That complexity has to live somewhere. Python is absolutely not straighforward, it's a huge language with many moving parts and gotchas. Although, I admit, both are very easy to start programming in and to start shipping broken projects that appear…

Many of us strongly prefer handling some complexity ourselves that we can then tackle with tests, CI, fuzzing, etc if it means we don’t have to jump through hoops to satisfy the compiler before we can even see our code running. Yes, Golang and Python and Java are very easy to start programming in. And unless we’re dealing with some really complex problem, like next-gen cryptocurrencies ;), by the time the Rust teams…

> the Golang/Python/Java teams have already released to customers.

...have already released a broken prototype that appears to be working for now.

I'm yet to see a case where manually "hardening" your software is faster than writing a "similarly-good" program in Rust. That's just anti-automation. Why repeat the same work in every project and bloat your codebase, when the compiler can carry that burden for you? In my experience, Rust makes you write production-grade software faster than when using other languages.

> But selling this approach as a general solution is disingenuous.

I agree! There are legitimate cases where releasing a broken prototype as quickly as possible is important. There's room for that.

But I agrue that it's not the case for most "serious" production software that would be maintained for any period of time. And that Rust is the preferable option for writing such production software.

Post reply on HN