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

41–50 of 319 posts

Re: A Rust shaped hole

#41

Post by Expurple »

> 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 explicit control flow isn't enough to actually enable local reasoning in the way that Rust (and some other functional languages) do.

I agree that Go is decent at this. But it's still not perfect, due to "downcast from interface{}", implicit nullability, and similar fragile runtime business.

I largely agree with the rest of the post! Although Rust enables better local reasoning, it definitely has more complexity and a steeper learning curve. I don't need its manual memory management most of the time, either.

Related post about a "higer-level Rust" with less memory management: https://without.boats/blog/notes-on-a-smaller-rust/

Re: A Rust shaped hole

#42

Post by pron »

> And the very point of writing a native program in the first place is to make it feel solid.

What does that mean, and what is it about native programs (i.e. programs AOT-compiled to machine code) that makes them feel solid? BTW, such programs are often more, not less, sensitive to OS changes.

> realizing that I was just spawning complexity that is unrelated to the problem at hand

Wait till you use Rust for a while, then (you should try, though, if the language interests you).

For me, the benefit of languages with manual memory management is the significantly lower memory footprint (speed is no longer an issue; if you think Haskell and Go are good enough, try Java, which is faster). But this comes at a price. Manual memory management means, by necessity, a lower level of abstraction (i.e. the same abstraction can cover fewer implementations). The price is usually paid not when writing the first version, but when evolving the codebase over years. Sometimes this price is worth it, but it's there, and it's not small. That's why I only reach for low level languages when I absolutely must.

Re: A Rust shaped hole

#43

Post by uecker »

tines wrote: post #31
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…

The two are incomparable in both quality and quantity. The complexity of Rust comes from the fact that it's solving complex problems. The complexity of C++ comes from a poorly thought out design and backwards-compatibility. (Not to slight the standards committee; they are smart people, and did the best with what they had.) Anothere way of putting it is, if you didn't care about backwards-compatibility, you could grea…

I would say that most of the complexity in both cases comes from overengineering.

Re: A Rust shaped hole

#44

Post by tines »

uecker wrote: post #43
tines wrote: post #31

Earlier quoted context omitted.

The two are incomparable in both quality and quantity. The complexity of Rust comes from the fact that it's solving complex problems. The complexity of C++ comes from a poorly thought out design and backwards-compatibility. (Not to slight the standards committee; they are smart people, and did the best with what they had.) Anothere way of putting it is, if you didn't care about backwards-compatibility, you could grea…

I would say that most of the complexity in both cases comes from overengineering.

Can you give some examples of Rust and C++ design that are over engineered?

Re: A Rust shaped hole

#45

Post by uecker »

dijit wrote: post #24
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…

You’re right that Rust is a ball of complication. I am a fan of Rust but it’s definitely a terse language. However there are definitely signs that they have thought about making it as readable as possible (by omitting implicit things unless they’re overwritten, like lifetimes). I’m reminded also about a passage in a programming book I once read about “the right level of abstraction”. The best level of abstraction is…

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

Re: A Rust shaped hole

#46

Post by tialaramex »

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…

I've seen this idea from a few people and I don't get it at all.

Rust is certainly not the simplest language you'll run into, but C++ is incredibly baroque, they're not really comparable on this axis.

One difference which is already important and I think will grow only more important over time is that Rust's Editions give it permission to go back and fix things, so it does - where in C++ it's like venturing into a hoarder's home when you trip over things which are abandoned in favour of a newer shinier alternative.

Re: A Rust shaped hole

#47

Post by Expurple »

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…

re:crates https://web.archive.org/web/20250420085150/https://wiki.alop...

Re: A Rust shaped hole

#48

Post by Expurple »

ashishb wrote: post #11

I actively seek out tools written in static languages. They are less fragile and have a longer shelf life. https://ashishb.net/programming/maintaining-android-app/

I agree so hard. That's why I use Hugo for my website. Speed was always only a bonus

Re: A Rust shaped hole

#49

Post by B4uler5 »

tines wrote: post #36
B4uler5 wrote: post #28

If anyone reads this and like me fears the difficulty and complexity of rust, but still wants a language that is competitive in performance, works for system level programming as well as something more general purpose definitely give Swift a go. Over the last year I’ve started to write every new project using it. On windows, on linux and mac. It is honestly a wonderful language to work with. Its mature, well designed…

How tied to the Mac ecosystem is Swift these days? Also, how is its type system and metaprogramming? Does it have type polymorphism, typeclasses, macros, etc?

Some of the functionalities in the core/foundation library don’t quite match between operating systems so sometimes you do need to put an “#if os(macos) do” etc, but for the most part its super straight forward working on one or another platform.

In terms of its language features it has all of those and more, sometimes too many in my opinion.

I personally favour languages that are clear in their vision. However at its core Swift is a highly performant language that is designed really well, has beautiful syntax, and in the last 5 or so years I have been impressed with its direction. It is being developed by a good team who listen to their community but not at the expense of the languages vision.

My favourite aspect of using it though is its versatility. Wether you’re working on embedded systems, a game, a web server, or even a static site generator, it always feels like the language is there to support your vision, but still give you the fine grained control you need to optimise for performance.

I also collaborate with a friend who is a Rust developer and he’s always super happy to work on a Swift project with me so I feel like that’s enough praise when you can pull a rest dev away from their beloved.

Re: A Rust shaped hole

#50

Post by uecker »

tines wrote: post #44
uecker wrote: post #43

Earlier quoted context omitted.

I would say that most of the complexity in both cases comes from overengineering.

Can you give some examples of Rust and C++ design that are over engineered?

For C++, just take lambda captures, you can do [&], [=], [a], [&a], [a = b] (and I probably forgot half), the many way you can do initialization in C++ became a meme, but it really permeates the whole language whose design is driven by enthusiasts and people who have an interest to make it more complex (trainers, book authors, consultants, etc.)

For Rust, I think it is a bit of a different story and it is harder to point to specific features. The language is clearly much better designed (because it was more designed and did not evolve so much) and because of its roots in functional programming. Just overall, the complexity is too high in my opinion and it a bit too idealistic and not pragmatic enough.

Post reply on HN