Hacker News Reader

  My language brings all the devs to the yard 
  And they’re like, it’s better than yours  
  Damn right, it’s better than yours  
  I can teach you, but I have to charge

https://www.youtube.com/watch?v=aVQEbD3NyDw

> https://www.youtube.com/watch?v=aVQEbD3NyDw

Hah, this sounds like it fits in the Nerdcore genre. Might need to go and listen to something by MC Frontalot because of nostalgia now. I've also heard some humorous tech songs by Dylan Beattie in the past (though his conference talks are even better).

Edit: As for the languages, it seems like there's still a lot of elitism, gatekeeping and bikeshedding going on, which was something that was spoken of in DevTernity 2022 as well (in addition to coupling in codebases and architecture being a big theme this year). Sure, sometimes one language might be superior to another, but for most purposes many of the popular (or even niche) languages can be good investments and just generally good enough.

> KILL DASH NINE

> No more CPU time

> I run KILL DASH NINE

> And your process is mine

Reminds me of this.

> Someone please explain

I think you know the answer. We can be a selfish and narcissistic creature and we often show our worst side on the internet since there are no repercussions. It's not as bad on HN but its definitely there.

When someone defends use of Electron they usually say it helps productivity so much, that the application would not be created if it would have to be done with a more conservative technology stack. I like to write my personal projects using C. I feel that I wouldn't have motivation to work on them if I would use Rust.

I do see many shortcomings of C, I see a lot of advantages of Rust. It is always a game of trade offs. Safety/correctness, speed of development, performance of applications. It all depends on many factors, familiarity being one of them.

Lately I am thinking if it is possible to write in a subset of Rust, that would essentially be C-with-Borrow-Checker. Not using most of stdlib and very limited set of libraries. I also look at all those Better-C languages and do hope for their maturity: Zig, Odin, Hare etc.

Have you learned Rust or used it for any significant project?

In my opinion:

- Rust is more productive than C

- Rust is easier than C, once you get past the initial bump

And it's not my opinion, it's just fact that Rust has practically the same performance as C.

I say this as someone who is currently actively maintaining embedded firmware with 10,000+ lines of C. It will be my last significant C project.

In my experience, the limitations imposed by the borrow checker actually make you express your ideas more clearly. In this way, you might be fighting the compiler, but when your code does compile, it usually does what you wanted it to (and is also designed in a much better way, since you're forced not to take the easy way to the finish line).

Rust is a replacement for C++ not C.

Rust macros are a disaster.

The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin).

#![nostd] still doesn't handle alternate memory allocators all that well.

My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity.

> Rust is a replacement for C++ not C.

I disagree. We're finding that it's a great replacement for C++, C, C#, and Java. It even fits to replace or compliment scripting languages like JavaScript, Python, Ruby, etc.

> Rust macros are a disaster.

Better than C macros or no macros at all. Could it be better? Certainly.

However, I don't think that Zig comptime is capable of the very important things that Rust macros enable.

> The whole kerfuffle around async and what had to be put into the compiler shows that Rust features don't compose well and don't allow the language to extend to unhandled cases cleanly (see: Pin).

Actually, I consider Pin as a triumph of the Rust way. By adding a simple rule (do not move this) you get enable a bunch of useful properties. And it only affects things which need it. It requires some understanding of you're working with it in unsafe territory, but the API surface keeps things safe for the average user.

> #![nostd] still doesn't handle alternate memory allocators all that well.

I don't know enough about it to say otherwise.

> My wishlist is C with just a bit of the Rust borrow checking and safety. I suspect that Zig or D will be able to get 80% of Rust's safety while only gaining 10% of Rust's complexity.

All of your problems with Rust are being worked on. Most of the missing features and pain points I see bright up are really just cases where the language hasn't filled the whole multidimensional space where orthogonal features interact.

Based on pace of development, you might see Rust fill out before Zig or especially D fulfill your dreams. Especially if you want actual memory safety.

> We're finding that it's a great replacement for C++, C, […]

So far this makes a lot of sense.

> […] C#, and Java. It even fits to replace or compliment scripting languages like JavaScript, Python, Ruby, etc.

Well, I see you found a new hammer.

I for my part would say that Rust is overly complex for most things where C# or Java, and especially any Scripting language, would be a good fit.

But that's the cool thing about a hammer. You can use it use it for everything! Even eat soup with it. ;-)

> Based on pace of development, you might see Rust fill out before Zig or especially D fulfill your dreams. Especially if you want actual memory safety.

But you know that D has a GC by default? You can't be "more memory safe" than that.

So I really don't get the remark about D here.

> I for my part would say that Rust is overly complex for most things where C# or Java, and especially any Scripting language, would be a good fit.

Algebraic data types, which none of those languages have, are incredible for representing states in your program. They help reduce our eliminate the type of logic bugs that often show up in UIs and such.

The lack of null and using Options instead is one such example.

Rust has fantastic libraries like serde which make de/serialization fast without a need for reflection.

In short, the Rust ecosystem has a tendency to produce amazingly helpful abstractions.

> But you know that D has a GC by default? You can't be "more memory safe" than that.

First of all, D with GC is not a replacement for C. Anything with a GC is not going to fulfill a systems language role.

Secondly, you can be more memory safe than a GC. Most GCs do not protect against data races, but Rust does. I'm unsure exactly where D falls there.

> Algebraic data types, which none of those languages have, are incredible for representing states in your program. They help reduce our eliminate the type of logic bugs that often show up in UIs and such.

> The lack of null and using Options instead is one such example.

> Rust has fantastic libraries like serde which make de/serialization fast without a need for reflection.

Well, sure. But I'm completely unimpressed.

I'm a Scala developer. I have those features available mostly since "forever".

(Modern serialization based on compile time macros is "only" about a decade old, so quite "new" in Scala).

> In short, the Rust ecosystem has a tendency to produce amazingly helpful abstractions.

They do what they can and the results are OK-isch. But Rust is lacking features. Especially when it comes to abstractions.

Rust would need at least HKTs (higher kinded types) and "context abstractions" ("implicits") to come even close to what's possible in Scala. But Rust type system is still rudimentary in comparison.

Also the meta-programming story is very weak in Rust. I was shocked as I learned that Rust's macros are only on the level of Scheme. That's a shame for a new language, imho.

The only really interesting part about Rust for me is its raw performance. I have to admit that I'm really envious in that regard. (Scala has powerful features but you pay usually a high price for them as the compiler still isn't able to compile that stuff away. The annoying part is that nobody really cares much. They're more concerned with compile times; even Scala compiles at least an order of magnitude faster than Rust).

But actually it's not bad at all that Rust is a small and simple language. It's easy to pick up. (At least if you already know things like HOFs, ADTs, type-classes, Option / Either & Future monads, working with immutable data, and all that).

The other languages with comparable performance are mind twisting and full of bobby traps in comparison. C has no features at all and is outright crazy. C++ has features but that stuff is even more crazy. But Rust is nice and clean! (At least regarding semantics. The syntax is a different story. Rust is one of the ugliest languages. Everything seems patchy and irregular. But OK, that's "only syntax". One gets used to it quite quickly; and they wanted to attract C/C++ programmers, so I can understand why such an ugly syntax was chosen).

> Better than C macros or no macros at all. Could it be better? Certainly.

I don't agree. I'd rather have no macros because that would increase the pressure on the core language and compiler to evolve properly.

Any usage of macros that has to atomize down to the molecules of the syntax tree and then reassemble them from the ground up is screaming Language Failure Here. Those kinds of macros should only exist until the core language either vacuums up the construct and makes it standard or declares the construct verboten at which point they should be excised.

Instead, Rust's procedural macros are spreading like the plague throughout the ecosystem.

> All of your problems with Rust are being worked on.

Unfortunately they're not being completed--which is far more important.

> It is always a game of trade offs. Safety/correctness, speed of development, […]

Where's the trade-off? If the result is buggy crap and/or a security nightmare it makes no difference whether it was "fast to develop".

Saying something like that is like saying that you could build houses much faster if you just didn't have to follow any safety regulations. If you would try that in the real world you would end up in jail sooner or later. But in the virtual world of software people really seem to think that such an "argument" is valid.

I'm eagerly looking forward to the EU finally (and hopefully soon!) removing the liability exceptions that are still in place for software. It's in the working. Than software products would fall under the same liability laws than any other products, and vendors going to be finally full responsible for what they ship to customers. The whole "I don't care about safety and correctness because there are no consequences" madness would come to a very abrupt end in case vendors would be liable and could end up in court easy for shipping subpar products that were manufactured not adhering to state of the art practices.

> […] performance of applications.

Rust and C are the same in this regard. So no "trade-offs" here.

>But it's the same in Rust threads, too.

Not really. Those are very rare and only happens when someone asking for alternative or make claims that something only Rust can do.

>And say "why not Rust".

The unwritten rule of HN:

You do not question or criticise The Rusted Holy Grail and the Riscy Silver Bullet.

> You do not question or criticise The Rusted Holy Grail and the Riscy Silver Bullet.

You forgot the Holy D Cup.

In other words don't be asshole to other people, unless you want them to stir drama. And if you are, make sure you have some decent ammo to back those claims.

Sorry, but hard no. Not everything in life is relative.

There are objectively better programming languages than others. Like there are objectively better vehicles than others…

The blind Rust fanboyism reached crazy levels by now; and Zig isn't a bad language. (It's actually even quite nice for what it is). But there are very valid rational reasons to prefer one over the other.

Zig is a new language that repeats 50 year old mistakes. That's a very valid reason to criticize it. No memory safety is a big NO in the year 2022! Over 70% of all software malfunctions—and what's even more important, almost 100% of all severe security issues—are a direct result of missing memory safety. Even this one prominent stubborn and arrogant C dude realized that memory safety is an absolute requirement for a new language. That's saying a lot!

Still I recommend Zig to C die-hards. Because it's a slight improvement, and those folks will stick to C anyway otherwise.

But anybody who isn't married to C, and is still mentally flexible enough, should look for a better language instead.

As there are not much C contenders, especially safe and modern ones, the most valid choice right now in that field is Rust. Love it or hate it. It's like that. (And this does not change even in the light of the fact that Rust is currently overpraised by a large margin, and for a lot of "rewrite it in Rust" projects just using a GC language would be a more sane approach. Also there a niches where C can't be replaced by anything for the time being. But that are quite small niches, and they will likely become even smaller over time).

i think the worst case of this is in the javascript ecosystem. i'm really sick of seeing open source groups arguing with each other on internet.

First off, you're judging group by the loudest/most obnoxious member. Plus this feeds into your existing biases. You didn't note same tone coming from members of D community.

Second. Regarding using C, how would you react if someone told you: "I prefer driving cars with seatbelts and airbags removed. I like the speed you get from the reduced mass." Me, I'm not gonna try to convince you. I just don't want to drive with you.

Third people like their tribes. Insulting some language is bound to cause some members of said languages to retort. See discussion about D and Rust.

Different maturity. Rust got similar comments when the first people started using it. I think Zig also gets some criticism because it rejects the idea that memory safety is important and worth protecting against on the language level.

I reject zig because its maintainer has a maturity problem when dealing with critics. That's all I'll say about it. Bring on the downvotes, but I don't trust the security of the language whatsoever.