Comment by hoelle | Hacker News Reader

Comment by hoelle | Hacker News Reader

> Zig does enhance on C, there is no doubt. I would rather write Zig than C. The design is better, more modern, and the language is safer. But why stop half way? Why fix some problems and ignore the most damaging ones?

I was disappointed when Rust went 1.0. It appeared to be on a good track to dethroning C++ in the domain I work in (video games)... but they locked it a while before figuring out the ergonomics to make it workable for larger teams.

Any language that imbues the entire set of special characters (!#*&<>[]{}(); ...etc) with mystical semantic context is, imo, more interested in making its arcane practitioners feel smart rather than getting good work done.

> I don’t think that simplicity is a good vector of reliable software.

No, but simplicity is often a property of readable, team-scalable, popular, and productive programming languages. C, Python, Go, JavaScript...

Solving for reliability is ultimately up to your top engineers. Rust certainly keeps the barbarians from making a mess in your ivory tower. Because you're paralyzing anyone less technical by choosing it.

> I think my adventure with Zig stops here.

This article is a great critique. I share some concerns about the BDFL's attitudes about input. I remain optimistic that Zig is a long way from 1.0 and am hoping that when Andrew accomplishes his shorter-term goals, maybe he'll have more brain space for addressing some feedback constructively.

> It appeared to be on a good track to dethroning C++ in the domain I work in (video games)... but they locked it a while before figuring out the ergonomics to make it workable for larger teams.

There are million-line Rust projects now. Rust is obviously workable for larger teams.

> Any language that imbues the entire set of special characters (!#*&<>[]{}(); ...etc) with mystical semantic context is, imo, more interested in making its arcane practitioners feel smart rather than getting good work done.

C uses every one of those symbols.

I think you're talking about @ and ~ boxes. As I recall, those were removed the same year the iPad and Instagram debuted.

> I think you're talking about @ and ~ boxes. As I recall, those were removed the same year the iPad and Instagram debuted.

Take criticism better.

A language choice on a project means the veterans are indefinitely charged with teaching it to newbies. For all Rust's perks, I judge that it would be a time suck for this reason.

Browsing some random rust game code: [https://github.com/bevyengine/bevy/blob/8c7f1b34d3fa52c007b2...] pub fn play<'p>( &mut self, player: &'p mut AnimationPlayer, new_animation: AnimationNodeIndex, transition_duration: Duration, ) -> &'p mut ActiveAnimation {

[https://github.com/bevyengine/bevy/blob/8c7f1b34d3fa52c007b2...] #[derive(Debug, Clone, Resource)] #[cfg_attr(feature = "bevy_reflect", derive(Reflect), reflect(Default, Resource))] pub struct ButtonInput<T: Copy + Eq + Hash + Send + Sync + 'static> { /// A collection of every button that is currently being pressed. pressed: HashSet<T>, ...

Cool. Too many symbols.

That first "random Rust game code" is in fact code I wrote :)

It's the same amount of punctuation as C++, or really any other language with C-like syntax.

I think this criticism is silly. Here's what your first example would look like in a language with keywords (where reasonable, perhaps like C#) instead:

  pub fn play<lifetime p>(in out self, player: mut ref AnimationPlayer lifetime p, new_animation: AnimationNodeIndex, transition_duration: Duration) -> mut ref AnimationPlayer lifetime p

But, this is still confusing! Let's remove even more symbols, and make the syntax more obvious by removing abbreviations:

  PUBLIC FUNCTION Play
  LIFETIMES
    P
  PARAMETERS
    IN OUT Self
  Player AS MUTABLE REFERENCE TO AnimationPlayer WITH LIFETIME P
  NewAnimation AS AnimationNodeIndex
  TransititionDuration AS Duration
  RETURNS MUTABLE REFERENCE TO ActiveAnimation
  BEGIN
  ...
  END

IMO, using keywords instead of symbols for references, lifetimes, etc, would just make Rust overly verbose, and there's a reason BCPL used braces instead of BEGIN/END :^)

> Any language that imbues the entire set of special characters (!#*&<>[]{}(); ...etc) with mystical semantic context is, imo, more interested in making its arcane practitioners feel smart rather than getting good work done.

On that scale COBOL is a better programming language.

Reply on news.ycombinator.com