Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Hope Rust Does Not Oxidize Everything

gavinhoward.com

Post reply on HN
Print view View original

41–50 of 195 posts

Re: I Hope Rust Does Not Oxidize Everything

#41

Post by sebstefan »

>the syntax. It’s ugly. [...] I would prefer something that is less sigil-heavy.

That's also one of my gripes with Rust. Very sigil heavy makes it hard to google syntax elements. What's the name of the `|` glyph? Especially challenging if you know the name of the glyphs in your language but not in necessarily in english. Double challenging for glyphs with several accepted names

But in the end, I'm big enough to realize that this is not a very important aspect of the language

If it's ugly so be it. I'll still learn it

Also for once Bing Copilot pretty much solved this for me since unlike google search, it's semantic + it doesn't ignore special characters

Re: I Hope Rust Does Not Oxidize Everything

#42

Post by fxtentacle »

noelwelsh wrote: post #3

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 and no C, you're of no use in embedded land.

I think that's the main reason why we don't move away from C: You still need a firm grasp of C if you want to be a capable higher-level developer.

C++ is then the logical upgrade because it's compatible with C and looks very similar. Java also did OK because it looks and feels very similar. And there's good automated C to Java converters. So you get the benefits of Java over C almost for free. Rust, on the other hand, throws away most of the C conventions and that makes it feel foreign and "incompatible".

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 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. Go had the same problem, but they had Google's weight behind them to push out tons of libraries. Who is doing that for Rust?

In the end, I agree with the article: Rust is great! when it fits. But there are still plenty of situations left where Rust is worse than old-school C.

Re: I Hope Rust Does Not Oxidize Everything

#43

Post by tormeh »

Ygg2 wrote: post #17
WhereIsTheTruth wrote: post #4

Projects adopting rust makes contributing less fun and more painful I tried to work on bug fix for Zed, waiting 30 seconds everytime you change a value was _very_ painful

What were you waiting on? You shouldn't have run cargo build every change. And cargo check shouldn't take that long.

This is a sort of odd phenomenon, but I've noticed that the Rust software I'm developing professionally is never actually getting run before it's pushed to production. We have some unit tests and run those, and if that's fine then into prod it goes. It's honestly a bit insane when I think about it, but it works...

Re: I Hope Rust Does Not Oxidize Everything

#44

Post by rapsey »

logicchains wrote: post #37
rapsey wrote: post #16

Earlier quoted context omitted.

Without a GC? No there is not. You are welcome to try of course, but unless you have a PhD in type theory I doubt your chances.

There's a smaller, simpler, safer language lying in Rust called "Rust without async", which would be good enough for the 99% of use-cases that don't need absolute-lowest-possible-latency async.

No one is forcing anyone to use async though. It is an entirely optional part of the language.

But it is naive to think that not using it is an easier path towards a solution.

Re: I Hope Rust Does Not Oxidize Everything

#45

Post by Avamander »

zkldi wrote: 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.

Fishtail, lifetime and closure syntaxes are rather ugly. Just specifically when combined in practice, not alone in isolated examples.

Re: I Hope Rust Does Not Oxidize Everything

#46

Post by pornel »

fire_lake wrote: post #13
noelwelsh wrote: post #3

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.

People reject OCaml for these use cases due to the GC, but I wonder if this actually matters in practice. The optimizations that can be applied to ML languages (see MLTon for example) are very advanced and the ability to do multi core with ease (I know this is more recent to OCaml) can be a big performance unlock that is very hard to get right in C.

GC is perfectly fine for ~99% of applications, which is why all the languages in the last few decades adopted it, and eliminated themselves from being direct C/C++ competitors.

Lack of GC isn't a requirement for most programs. However, it is a requirement for a language meant to actually replace C and C++, because these two are mostly used in the remaining fraction of programs and libraries where any GC or any fat runtime is undesirable. Even where some GC could be made to work, it makes it a tough sell for C/C++ users.

Re: I Hope Rust Does Not Oxidize Everything

#47

Post by actionfromafar »

cassepipe wrote: post #31
fire_lake wrote: post #14

Earlier quoted context omitted.

OCaml could almost replace all of those. I don’t think there is a BEAM compiler backend yet. I’m not very experienced with BEAM, but could its features be delivered with a framework on top of a different stack? I know Akka is popular.

The OCaml backend for the BEAM was called Caramel but has been abandoned after his author went on working on hiw own build system, warp.

Build systems come for our best and brightest. :-(

Talk to your friends and family.

Re: I Hope Rust Does Not Oxidize Everything

#48

Post by dtquad »

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.

Re: I Hope Rust Does Not Oxidize Everything

#50

Post by DEADMINCEDOS »

jltsiren wrote: post #26
noelwelsh wrote: post #3

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.

My favorite hypothesis here is that programming language enthusiasts are too different. They are incapable of convincing the average programmer of the merits of their favorite language, because their way of thinking is different. Arguments they find convincing are not convincing to the average programmer. Progress happens incrementally with small steps. Existing languages get new features. New languages get popular,…

I think you're right. The same way people have strong preference for Systemd, MacOS, KDE, Gnome, I3, Nix, Debian, Gentoo, Arch, etc.

So many different solutions. Most are preferred because of subjective reasons (although sometimes just poor reasoning period), because people think so drastically differently.

Post reply on HN