Hacker News Reader

Comment by seumars | Hacker News Reader

  >The advantage is that [learning Rust] automatically filters, uh…, script kiddies
  >So if you want to hire someone to write Rust for you, it’s pretty safe.

I'd be really sceptical of hiring someone who refers to other developers as "script kiddies". Rust has been getting a lot (well deserved) attention but I hope people aren't learning Rust as a status symbol.

View on HN

Also, it's an attitude completely antithetical to that which the Rust community tries to cultivate.

Literally, the very first sentence on rust-lang.org is "A language empowering everyone to build reliable and efficient software." Making "real" a systems programming language that is more accessible is one of the primary goals of the language. And a large portion of the Rust community are converts from scripting languages like Python / Ruby / NodeJS, and the tooling is inspired by (good parts of) the tooling that sprang up in those communities.

If you want to think that way about "script kiddies" then that is your right, but keep it to yourself.

The Rust community really has a problem with some of its fans and zealots there (far from the only programming language community to do so of course, but I can't remember seeing arguments that users of the wrong language should be tried in Den Haag in other places...).

> but I hope people aren't learning Rust as a status symbol.

Of course they do. Lots of learning today seems to be based around "what looks nice to put on my resume?" which is effectively a status symbol, rather than choosing tooling that is actually the best for the job.

Same applies for a ton of stuff as well, not just Rust.

"Resume-driven development"

Web development > personal development

No, that's something else. Choosing languages in order to look better on the resume is not personal development, it is resume-driven development. Learning new languages in order to become a better programmer overall is personal development, or learning languages that fits better with "you as a person". But chasing hype is not "personal development" and that meme needs to die.

Sad and true. The other side of the equation is people being forced to work under abysmal constraints, because of technical choices made years or even decades ago.

That being said, "Rust on the frontend" sounds pretty ridiculous to me.

I'm sorry for not having read the article before commenting.

Not more ridiculous than C++ on the frontend — which is typical if the frontend is a native GUI.

Correct, I was failing to take off my web dev hat

From what I've seen, most frontend Rust development is focusing on replacing C/C++/C# frontends, not necessarily for websites or even really desktop applications.

With that being said, I have written a few GTK+ applets in Rust, and I gotta say that it's not as bad as it sounds or looks. The current GTK crate supports Glade, meaning that you don't have to actually write your frontend in Rust, rather building it in a different program, exporting it as glorified XML and binding the intractables to different buttons and fields. A hello world-styled GTK demo is only a few lines, and of course you get a wickedly performant binary out of the process too (mine used 4mb of memory, which could have been further optimized).

Thanks for the informative reply!

As someone with limited experience, how do you deal with animations and such in GTK/Glade? Took a look at the Glade website (https://glade.gnome.org/) and doesn't seem mentioned. In fact, I cannot even find a list of supported features.

(Disclaimer: I have no idea what I'm talking about)

I wouldn't be surprised if you could/had to do something similar to this sprite handling example[1], where instead of updating the sprite's location you update widgets' attributes. This would be a "manual" process, but it should work (if repainting widgets is fast enough).

[1]: https://github.com/steshaw/gtk-examples/blob/master/ch13.spr...

Animation is handled by the compositor I'm pretty sure. Since different Linux desktops have different performance requirements, some will opt-in to using more fancy animations, whereas less powerful ones will disable them.

For everything else, you'd probably need to use some bespoke activators to achieve the effect you want. Not terribly hard to spin up, but it's definitely less simple than languages designed for frontend development.

> Animation is handled by the compositor I'm pretty sure. Since different Linux desktops have different performance requirements, some will opt-in to using more fancy animations, whereas less powerful ones will disable them.

I... don't understand what this means.

Let's say in GTK/Glade I want a Button that when you click on it, it moves from the bottom-left corner to the top-right corner. How do I archive this in that GUI builder or even with the XML spec?

I haven't done anything like this myself, but you can directly manipulate the location of UI elements in realtime. Failing all else, Rust is at least low enough level to impliment a frame-by-frame redraw... but that would be a very yucky way to do that.

Replacing C# with Rust for front-end sounds equally ridiculous.

C# is much higher level and ergonomic to use for this, the tooling alone is lightyears ahead for the job - compile times/debugging for GUI iteration alone.

I can understand using rust for front-end to slap some simple gui on top of some complex lib and allows a lot of reuse (although I would still prefer GUI using rust through an interface from higher level like FFI/IPC).

(author of post here)

I didn't get the impression from speaking with Martin that he was trying to gatekeep. He's spent a lot of time on github and in discord helping people learn Seed and MoonZoon.

In the context of hiring, I think the signal he's talking about is the same for any minority language like Haskell or Elixir. If you're spending nights and weekends hacking in a language that's not widely used in industry, it's an enthusiasm signal. This was true for Python about a decade ago, even though it's an easy language to learn. If you hired python developers, it was a signal that you'd be getting passionate enthusiastic developers.

As Rust becomes more adopted and hiring goes up, I think the value of that signal will go down. Rust certainly has complexity, but I don't think they're insurmountable barriers for any significant class of developers.

On the other hand, it might send potentially negative signals. Someone who "hacks" on a less-used language might have a programming language fetish, i.e. "why would you ever use Java...Rust is better in every way". And yes, I've met a few of those.

I also think the logic is flawed.

Usually I see comments like this from people who think "Frontend is easy, backend is hard" and then you look at the frontend code and you scream in pain.

Its not like you can not write bad code in Rust. Rust has for example 6 String types. You can also write unsafe rust code. There were example in the past were major Lib's did it just to make it faster.

Also the rust frontend eco system has a very low maturity. So you probably will be writing a lot of stuff on your own (what script kiddies do because they think they can do it better).

If for you it is important to have someone which is not a script kiddie then you could also go for someone who understands RxJS and Angular. This would also "filter".

I'm not sure how many people you will find with good rust skills and good UI/UX skills. If this is not important then go for it.

Six? I can think of String (owned bag of utf-8 bytes), &str (reference to utf-8 bytes), and OsString (potentially non utf-8 depending on your platform, used for ffi).

Some people say Cow<str> is a string type, but I think it's better thought of as a genetic type you often use with strings.

People say "Rust has six string types" but what they mean is "the standard library has six string types". Rust-the-language has one string type: str. The standard library also has:

  * String
  * OsString / OsStr
  * CString / CStr

if people really want to make it look big, they also include PathBuf/Path and Cow<str>.

Thanks! I'm definitely often guilty of conflating the stdblib and the language.

I prefer to think of it as programers have used strings to represent too many non-string things in the past. It's nice to look at a function sig and see Path/camino::Utf8Path/bytestr::ByteStr and see what they actually plan on doing with it.

Are there people who don't use the stdlib?

and then start to implement things that are in the stdlib?

Yes, for example, I am doing embedded development and do not use the standard library at all.

There's not a lot of reason to re-implement it, because if you can use it, there's not a lot of reason to not just use it.

There are people who make even more string types as packages, and use those. smallstr and bstr are two examples of those.

Sure fair point on embedded devices I can see it.

In the context of Backend/Frontend development I would question it.

I had a colleague who rewrote some string functions in Java which are part of the stdlib. He called them "Arne Tools". Arne is a name in Germany. We were doing Java Applets back then.

I always have to think of that example :D

Sure, but just because it’s in the standard library doesn’t mean you use it all the time. 95% of my usage on non-embedded targets is String and &str. The “six string types” makes things seem far more complex than they are.

It's commonly called no_std, after the attribute #![no_std]. People use it in embedded devices, and they're considering using it in the Linux kernel

Unsafe Rust is not automatically bad. The main reason all of those major libraries got switched to safe Rust is that progress in language features made it possible to do the same operations safely.

I don't wanted to imply that unsafe rust is bad.

The argument was that you can disable it easily.

For good and bad reasons.

> Unsafe Rust is not automatically bad

Correct me if I'm wrong, but isn't one of the main selling points of Rust that's it's "safe"? If you're using "unsafe" Rust, you might just go for more established languages straight up.

The unsafety is localized to the rare `unsafe` blocks, which are not allowed to compromise the safety of the rest of the program.

You can still have the compilers check a few things, even in unsafe code.

Besides, having 95% safe code and 5% unsafe code is still going to help when working on the rest of the codebase

Rust's main selling point is a type system that allows safe wrappers around unsafe code by encoding invariants in the types themselves. Stuff that lives in the documentation like "you need to call foobar_free" becomes an unsafe block in a safe Drop implementation that only needs to be extensively tested once to validate the safety of the wrapper. Once the safe-unsafe interface is tested, downstream code doesn't have to worry about the unsafe implementations at all.

Without unsafe, Rust programs would be useless since the Rust compiler can't verify the safety of external libraries that provide critical functionality like memory allocation and syscal interfaces (I/O). It would also go against one of Rust's main goals which is C FFI compatibility, which is something that the Rust compiler can't verify.

It's more about how strongly typed the language itself is. Rust isn't necessarily harder to learn than a scripting language, but a lot of it's syntax is dependent on how well you understand programming fundamentals. For example, you can't just spin up an integer at will in Rust: you need to specify how many bits you're using, and manually sign or unsign each value to manipulate it accordingly. That's the stuff that will filter out JS writers and Python devotees.

It's not really an insult so much as it is commentary about the language. The focus on zero cost abstraction and correctness at compilation means that it's harder for a Rust dev to write a slow program than it is for a Python or Java dev. Again, not necessarily because of any fundamental issues with the other two languages, but rather that Rust is a pickier language.

> For example, you can't just spin up an integer at will in Rust: you need to specify how many bits you're using, and manually sign or unsign each value to manipulate it accordingly.

    let x = 5;

I mean, you can do this, but it will still get automatically typed as a u8, which could very easily cause confusion for Python devs who really want to push that value past 255. My bigger point (and likely the authors) was that Rusts integers aren't like Java's ints or Python's bigints. Your laziness in that example is still being penalized, it's just harder to see and therefore, less "correct".

FYI the default is i32, not u8.

  it's harder for a Rust dev to write a slow program than it is for a Python or Java dev

Like C and C++, Rust is by default fast, but the language itself does not provide features that make it easier to write fast code.

Not just that - using complicated solutions in situations they offer few benefits and a lot of downsides to establish tech is a massive red flag for me.

The worst project I've ever worked on was a C# project where some random mid-level dev thought he was smarter than anyone for learning functional programming. He wrote his own Monad framework that abused LINQ syntax for composition, everything was littered with this bastardised Maybe implementation, he used delegates all over the place - including dependency injection containers, etc.

By the time I came on the project it was years into development and the original guy left years ago. It was the worst mess you ever saw - months long onboarding, unreadable code, stack traces full of useless shit, impossible to lookup where specific dependencies were coming from in the project.

A very technical but immature developer is much worse than a below average dev.

Reminds me of http://www.paulgraham.com/pypar.html

I saw this same attitude on a Haskell shop - "we write UIs in Haskell to prevent hiring script kiddies". Turns out Haskell coders with 20y of experience on completely non-visual workloads are terrible at UI/UX, to the point of dismissing the work of building the UI as "a lesser concern".

That's orthogonal to the discussion.

You would anyway need UX designers for that, the issue is leaving that to the developers.

I do my own design sometimes but when I implement a well designed design by a real designer the end result is years light ahead

Developers sneering at other developers is relevant to a discussion about gatekeeping.

Rust should not be a status symbol, but as someone very wary of Rust-hype myself, I'm very wary of the number of 1/2 developers out there.

There are people who pick up a few lines of JS, a few lines of Python and are technically 'developers'.

There are others with much stronger fundamentals.

PG was big on using arcane languages as a form of natural selection, Rust may be nice for that, in the sense that I think anyone who can approach rust and make an app with it, probably fits in the 'developer' camp at least on some level.

I like it because when looking for C++ people, I also want people who have enough self-awareness, and Rust makes you think about things in a different way, and at least contemplate some of the bad habits that exist in C++.

Exactly. Everyone knows that you need at least Haskell to filter out these pesky fashion victims. /S

The wording may be harsh, but the idea is roughly correct. Learning Rust and fighting the borrow checker requires CS fundamentals knowledge.

However, that doesn't mean the person can write concise code or have good soft skills, or be a good hire.

I'll be a bit raw, sorry for it. There is a battlefield in the JS ecosystem. Anyone seasoned in it, with all that entails, is not your "script kiddie" as that word originated in a VERY different era, with very different requirements for said "script kiddies". If anything, it shows that the one using this phrase is a bit out of the loop.

(author here) I probably should have mentioned it more prominently in the post, but Martin's first language isn't English (he's Czech). So not out of the loop, but the exact connotation of the phrase is something I personally cut him slack on

Once Rust breaks into the top 10, there will be plenty of people writing lazy rust and sprinkling `unsafe` throughout their code.

This whole argument is exclusionary and divisive.

Rust is a language whose selling point is safety so I don't see unsafe code appearing often no matter its popularity.

I do agree that it is divisive, but sometimes it also feels like humbleness of research programming languages (esp. Haskell) designers is a bit faked, which can have the opposite effect and scare beginners. The most popular languages, who beginners love, tend to have a history of being designed to be practical, not well designed or researched.

I have a tiny bit of Rust experience, and honestly if someone taught me Rust as a first programming language, I'd get so frustrated and insecure. Don't get me wrong, it's a beautiful language and the online book is great -- but it has a great barrier to entry and most people would get frustrated. Meanwhile, people following JS tutorials will already feel dopamine hit from getting their own programs running on screen and will be motivated to continue their journey.

> I hope people aren't learning Rust as a status symbol

There was another reason for its existence??

Perhaps.

But let’s say you have two resumes in front of you. One person has only worked in interpreted languages and the other has worked in interpreted languages as well as in C, C++, Go, Rust..

Both of them clear your technical interview.

Which candidate will you pick?

I would say that's not enough information...

And getting a candidate because of that one metric would be insane..

Not enough information. It largely depends on the product, the team, and even soft skills or domain knowledge.

In some contexts, yes having knowledge of compiled or non-GC languages is critical. But there is a certain baseline of programming knowledge that allows any dev to be decently productive; for many products & teams, soft skills become more important after that point. For example: if the interpreted lang dev is great at communicating and the compiled dev is terrible, some teams may elect to choose the first for that reason alone.

You could also argue that it puts you at risk of hiring someone from the other end of the spectrum: a knowledgeable senior dev that is more interested in writing over-engineered solutions for the fun of it, rather than matching the solution to the problem.

Rust is great and shows a lot of promise, but I think you need to have some strong arguments when using a lower-level systems language outside of a systems-focused context. Not saying it can't/shouldn't be done, but it's worrying to me when people stop thinking critically because of the hype.

Reply on news.ycombinator.com