Live data from Hacker News

I Hope Rust Does Not Oxidize Everything

gavinhoward.com

71–80 of 195 posts

Re: I Hope Rust Does Not Oxidize Everything

#71
post #28

The post is a bit of a rant and all over the place. Async infecting everything, ugly syntax (who cares?), slow compile times etc. What stood out to me: > In other words, if compilation is fast, the tooling is easy. Andrew Kelley said something similar in a recent talk. Compiler performance seems to be the number one priority at the moment for Zig. The rationale seems to be: fast compilation leads to more productivity…

> ugly syntax (who cares?)

Code is meant to be read, so a lot of people care actually.

Sure it's not the only thing that contributes to the usefulness and appeal of a language, but reading code is still one of the two main things we do with it so it's quite important to nail the syntax right.

Re: I Hope Rust Does Not Oxidize Everything

#72
post #7

This is my current mental model for picking a language, considering just the language itself: - Backends: Gleam or other BEAM - Web frontend: Gleam - Mobile apps: Dart + Flutter - Specialized mobile apps: Swift and Kotlin - Blazing fast: Zig - Blazing fast and safest: Rust - Fast performance and iteration: Go Would love to hear additions and corrections. My only problem with this is I'm not a fan of Go's syntax and I…

I’m super into elixir now and don’t see myself going anywhere else. Is gleam really that good? What are the advantages? Can I use liveview with it?

As far as I know Gleam is the only strongly typed language on BEAM, which is important to me since I don't like dynamically typed languages. But of course Elixir gets optional types now.

Re: I Hope Rust Does Not Oxidize Everything

#73
post #57
post #36

I'll bite: What specific parts of rust syntax do people find so ugly? I keep hearing this from decent chunks of people who don't write rust, but the language doesn't seem that far off C to me. It's certainly no haskell.

The more interesting follow up question is: "How would you express the same semantics with a different syntax?" Too often discussions about Rust's ugly syntax lack this crucial component.

> How would you express the same semantics with a different syntax?

This isn't the problem, the problem is "... and keep the syntax C++-like?".

Re: I Hope Rust Does Not Oxidize Everything

#74
post #27
post #19

Earlier quoted context omitted.

This, I don't understand why we have to load these languages up with so much syntax, it's mind boggling to think that some how we feel it's beneficial to have so much. I'm admittedly biased to the symbolic expression but surely we could have come up with some middle ground.

Two things: - It was made to be approachable for C++ experts - The idea was that language could be effortlessly greppable.

Coming from C++, and I would have loved Rust to not pick up C++-y things to make it look like it...

Re: I Hope Rust Does Not Oxidize Everything

#75
The post doesn't seem to mention certain parts of the community, which is basically my main issue with Rust.

You can't even mention that bootstrapping the compiler is a process that's way too convoluted, because you get buried to oblivion ("why would you need that"). Thankfully there are some already, though incomplete because (I'm guessing) Rust being mostly defined as "whatever rustc outputs" doesn't help reduce the pain of checking if your implementation is correct. I appreciate the efforts that are going on to write informal non-spec documentation about the language though, better than nothing.

Also can't mention that alternative compilers would be nice (e.g. to make bootstraping easier, see previous point), because you also get buried to oblivion ("don't fragment the ecosystem", "the Rust council/teams/etc will always be composed of trustworthy people now and forever").

Like, yes, but chill a bit and try to consider other use cases instead of reading those topics as attacks to the language just because you think you don't need them. A small minority being very loud in rejecting any attempt at healthy discussion is not good optics for the ecosystem.

This stuff also happens with other languages' communities, but somehow I seem to find them happening a lot more frequently with Rust.

(P.S.: Changing the topic a bit, I'll invoke Cunningham's Law and say there's no easy way to read Rust documentation offline that doesn't require a web browser of some kind or parsing HTML output. Some equivalent to `go doc` or Python's `help()` function.)

Re: I Hope Rust Does Not Oxidize Everything

#76
post #57

Earlier quoted context omitted.

The more interesting follow up question is: "How would you express the same semantics with a different syntax?" Too often discussions about Rust's ugly syntax lack this crucial component.

> How would you express the same semantics with a different syntax? This isn't the problem, the problem is "... and keep the syntax C++-like?".

Is it? I don't know if keeping Rust's syntax C++-like is a stated goal of the project, but okay sure we can add that caveat to my question.

The big problem I see is that people will say "Lifetime annotations are ugly and noisy" and when pressed on the issue will eventually concede that they just want GC(which is not about syntax, but semantics)

Re: I Hope Rust Does Not Oxidize Everything

#77

Maybe that will sound banal to some but C would be so much more enjoyable to me if it had a "cargo" system and no implicit imports.

That's the problem with C. It cannot have a sane cargo like system. The language is not built for writing libraries. There is a reason why everyone keeps reinventing the wheel when it comes to datastructures in C. Where is STL for C?

The closest is GLib and it's absolutely not fun to work with.

Re: I Hope Rust Does Not Oxidize Everything

#78
post #48

I have seen a lot of criticism of async Rust. In C# most APIs expose both sync and async versions of the same methods. Why is that not more common in Rust? Sure some 3rd party C# libraries probably do some ugly sync to async conversion internally but most don't and use the .NET standard libraries sync/async versions of the same APIs.

Rust's async is in some places more difficult to use, because Rust is obsessed with avoiding allocations and dynamic dispatch.

Languages like C# and JS allocate a new object for every Promise and every listener. Rust bends backwards to avoid that, and make inlined strongly typed state machines instead. It creates limitations where you wouldn't expect, e.g. recursive calls need special handling, and abstract interfaces don't fully support async.

As for supporting both, it's just inconvenient to do, because many small syntactic and semantic differences mean it's hard to automate and cumbersome to maintain.

Re: I Hope Rust Does Not Oxidize Everything

#79

Rust is certainly not the last word in systems programming languages, but it's an huge leap forward from C and C++. To be honest, it's a sad reflection of our industry that it's taken this long to get basic safety + ML circa 1975 language features into this niche. If things had turned out a little bit different we could all have been using OCaml for the past few decades.

Sadly, Rust is only a "huge leap forward from C and C++" for some use-cases. Simple things like returning a const reference to a slot in an immutable array are easily 10x the amount of source code in Rust when compared to C. And all the standard libraries for embedded systems are C, so to get into embedded development, you definitely need to be good at reading C code. Rust is an additional skill, but if you only know…

> Rust also suffers from a serious "not invented here" problem, in my opinion. It's super easy to re-use C code in C++ or Java. It's significantly more difficult to re-use C in Rust ...

It feels like a mischaracterization of Rust and I strongly disagree. Both the language and tooling are designed from the beginning for interop with C code. It isn't very hard to do if you have tried it.

> ... unless you go unsafe and abandon most of the Rust advantages. That means most dependencies need to be re-implemented in Rust if you want to have all the advantages that Rust offers.

This 'Rust is useless if you use unsafe' is a stance that is well debunked, but still gets repeated like this. Ensuring safety using Rust semantics across an FFI with a language like C is impossible - making unsafe necessary. But just because you use unsafe doesn't mean that the language lost most of its advantages. In fact, almost every Rust program uses unsafe code, if you care to look at the code in the standard library. Yet, that never seems to be a problem.

What unsafe does is to cordon off a small code area where certain invariants have to be asserted manually, instead of relying on the borrow checker. You still get the safety for the rest of the code. In case you do get safety violations, there is much less code to debug. This is a significant advantage over languages like C++, considering that unsafe blocks are usually less than 5% of the code, even in the worst case. But to take it further, C libraries often have corresponding Rust wrapper libraries that create safe wrappers over C FFI calls. In addition to the small unsafe blocks to verify manually, these wrappers have the additional advantage of being widely used and debugged by a wider community. There are innumerable such wrappers on crates.io and it's uncharitable to accuse the language of NIH syndrome.

Re: I Hope Rust Does Not Oxidize Everything

#80
post #67

A lot of this author's complaints about Rust remind me of similar historical complaints about C++, but amplified. Hijacking and overtaking new projects? C++ and Rust both do that. C++'s compile times were a joke, Rust is even worse. Complex semantics and syntax? Both have those. Rust is trying to be everything to everyone? C++ has always been criticised as design by committee. And yet C still exists and is widely use…

Do you mean that once the Rust smoke clears, people will see C++ as much more tolerable and usable? :')
Post reply on HN