Comment by flohofwoe

Comment by flohofwoe a day ago

> Zig is better, yes, but not a paradigm shift.

But it doesn't have to be and it shouldn't. Rust also isn't a paradigm shift, it "just" solved static memory safety (admittedly a great engineering feat) but other languages solved memory safety too decades ago, just with more of it happening at runtime.

But in many other areas Rust copied too many bad ideas from C++ (and many of those "other things" Zig already does much better than Rust - but different people will have vastly different opinions about whether one solution is actually better than another - so discussions about those features usually run in circles).

There shouldn't be a single language that solves all problems - this will just result in stagnation, it's much better to have many languages to pick from - and even if they just differ in personal opinions of the language author of how to do things or entirely subjective 'syntax sugar' features. Competition is good, monocultures are bad.

> The most important consideration in any software project is managing architectural complexity

No language will help you managing "architectural complexity" in any meaningful way except by imposing tons of arbitrary restrictions which then get in the way for smaller projects that don't need much "architecture". We have plenty of "Enterprise-scale languages" already (Java, C#, Rust, C++, ...), what we need is more languages for small teams that don't get in the way of just getting shit done, since the really interesting and innovative stuff doesn't happen in enterprise environments but in small 'basement and bedroom teams' :)

simonask a day ago

You put "just" in scare quotes, but that word does a lot of heavy lifting there. Static memory safety is an extremely useful thing, because it enables you to do things competent programmers would never dare in C, C++, or Zig. Things like borrowing data from one thread's stack in another thread, or returning anything but `std::string` from a function. These things were simply not feasible before without a huge bulky runtime and GC.

Keep in mind that Rust's definition of "memory safety" covers much more than just use-after-free, the most important being thread safety. It is a blanket guarantee of no undefined behavior in any code that doesn't contain the word `unsafe`. Undefined behavior, including data race conditions, is a major time sink in all non-hobby C or C++ projects.

What bad ideas from C++ did Rust copy, in your opinion? I'm really not sure what you mean. Smart pointers? RAII?

There are plenty of languages that enable quick iteration, prototyping, or "just getting shit done". If that's what you need, why not use them? I'm personally more concerned about the finished product.

Reply View 13 replies

Mawr 17 hours ago

You know, I'm beginning to understand why people complain about the "Rust Evangelism Strike Force". Can we discuss a language without the constant "But why not Rust instead?!", pretty please?

Reply View | 1 reply
- simonask 12 hours ago
  
  I did not bring up Rust.
  What are you saying? Do you think I was sent here by some sinister cabal that organizes an effort to direct any discussion about programming towards Rust?
  
  Reply View | 0 replies
flohofwoe a day ago

> You put "just" in scare quotes
...I don't use them as "scare quotes", it's more like in "can't you just..." - e.g. something that looks simple from the outside but is hard to do / complex on the inside - e.g. I do recognize the work that went into Rust's memory safety, but I question the effort that went into it compared to more traditional memory safety methods, especially when looking at the restrictions that Rust imposed on the programmer - it's a pretty hefty tradeoff (IMHO of course).
> What bad ideas from C++ did Rust copy, in your opinion?
Mainly doing things in the stdlib that should be built into the language (e.g. Option, Result, Box, Cell, RefCell, Arc, and probably a dozen other types and traits...), resulting in what I call 'bird droppings syntax' of too many chained function calls to get to the thing you actually want (.unwrap, .into_iter, .iter, .iter_mut, .as_ref, .as_mut, .expect, .unwrap_or_else, .unwrap_or_default, .ok, .ok_or_else, .and_then, .or_else ... like, wtf?). The absurd amount of `::` and `<>` in typical Rust code. The missing separation line between stdlib and language (like for-loops using the Iterator trait, or more obviously: operator overloading). The stdlib doing memory allocations behind your back through a global allocator - which we know from C++ do be a really bad idea for decades already... etc etc... I think most Rust programmers are blind towards those issues the same way that C++ programmers are blind towards C++ issues (which is another thing both language ecosystems have in common though).

Reply View | 10 replies
- simonask a day ago
  
  I mean, there's no winning here. Either the language is too complex and does too many things, or it's not complex enough and relegates fundamental things to the standard library.
  I don't thing there is any substantial difference between `Option<Thing>` and `@Nullable Thing` or `Thing | null`, I don't think there's anything wrong with choosing `::` over `.` for namespace resolution (it means you can have local variables with the same name as a module), and you have to have some way to declare generic parameters.
  Rust generally does not allocate behind your back, but custom allocators is a work in progress. The reason it takes time is precisely that they want to avoid the mistakes of C++. A couple of mistakes were already avoided - for example, async/await in Rust does not allocate behind your back, while C++ coroutines do.
  
  Reply View | 9 replies
  
  tialaramex a day ago
  
  > I don't thing there is any substantial difference between `Option<Thing>` and `@Nullable Thing` or `Thing | null`
  I object to @Nullable and similar arrangements as a magic special case. If the sum types only solved this one issue then it's a wash but they do a lot more too.
  Either of the sum types, the concrete `Option<Thing>` or the ad hoc `Thing | null` are OK because they're not magic, less magic is better.
  
  Reply View | 4 replies
  
  throwawaymaths a day ago
  
  doesn't the llvm coroutines require c's malloc? this is part of the reason why zig scrapped async. i would suspect Rust's async/await does allocate behind your back
  
  Reply View | 3 replies