Yes, I am still learning Rust(llogiq.github.io)
llogiq.github.io
Yes, I am still learning Rust
https://llogiq.github.io/2020/03/07/learning.html
12 comments
That’s tough because often I’ve had coworkers who give their thumbs up or thumbs down based on “he had it on his resume and I asked him basic question X and he had no idea, terrible”.
You should be able to answer the basic questions, but you shouldn't need years of professional experience with something to feel like you can list it without a "learning " prefix
"He used a for loop instead of a list comprehension. he clearly isn't actually a Python programmer" -- actual debrief comments :|
I flunked an interview in a similar manner several years ago.
Hadn't done Java in around half a decade but the company recruiter said that it's not an issue (they contacted me).
Then I got a 30-minute online coding test that I had to do in Java. Took me a while to remember the syntax but finished the required problem in time and without issues/bugs.
In the end I got dinged for not using the Java Arrays library for copying an array (used a manual for loop)...
Hadn't done Java in around half a decade but the company recruiter said that it's not an issue (they contacted me).
Then I got a 30-minute online coding test that I had to do in Java. Took me a while to remember the syntax but finished the required problem in time and without issues/bugs.
In the end I got dinged for not using the Java Arrays library for copying an array (used a manual for loop)...
> In the end I got dinged for not using the Java Arrays library for copying an array (used a manual for loop)...
This doesn't sound like a smart interviewer. They are testing your knowledge of the library ahead of understanding what's going on. I'm pretty sure I've interviewed some people who could pull out Array.Copy for the interview but couldn't tell you that it does pretty much the same as the for loop, and that is much more alarming.
This doesn't sound like a smart interviewer. They are testing your knowledge of the library ahead of understanding what's going on. I'm pretty sure I've interviewed some people who could pull out Array.Copy for the interview but couldn't tell you that it does pretty much the same as the for loop, and that is much more alarming.
> This doesn't sound like a smart interviewer.
I was slightly upset/angry at first but after thinking about it I came to the same conclusion and ended up being happy that I didn't get to pursue the opportunity any further.
I was slightly upset/angry at first but after thinking about it I came to the same conclusion and ended up being happy that I didn't get to pursue the opportunity any further.
If someone claims to be an experienced python developer and fails to write idiomatic python then his claims are clearly contrasting with his output. I won't argue if prior experience with a language is relevant or not for a job application, but lying in the CV and misrepresenting the work experience and skills is clearly a negative mark on a candidate.
Personally I wouldn't want to work at a company like that
That’s called privilege
A currency we have in fluctuating quantities
A currency we have in fluctuating quantities
That's fair. But I don't just say that because it strikes me as annoying. That sentiment of "a real Python programmer" speaks to a mentality of in-group superiority, which could mean pettiness when it comes to decision-making, and possibly even toxic, hubris-driven interpersonal dynamics.
It could be anywhere from a mildly less effective team to a highly toxic work environment. That could matter in a real way.
It could be anywhere from a mildly less effective team to a highly toxic work environment. That could matter in a real way.
> That sentiment of "a real Python programmer" speaks to a mentality of in-group superiority,
I don't agree with you at all. By the context, the term "a real python programmer" clearly meanys a developer who actually has used Python in the past in a remotely significant way, at least slightly above the level of an intro to Python tutorial. Knowing the syntax is not knowing how to use a language.
It isn't elitist or classist to see red flags in a C++ programmer who fails to use smart pointers or doesn't understand the difference between pass by value and pass by reference. If someone passing himself as an experienced C++ programmer fails to allocate memory with new and just throws mallocs around, the reaction would be the same.
I don't agree with you at all. By the context, the term "a real python programmer" clearly meanys a developer who actually has used Python in the past in a remotely significant way, at least slightly above the level of an intro to Python tutorial. Knowing the syntax is not knowing how to use a language.
It isn't elitist or classist to see red flags in a C++ programmer who fails to use smart pointers or doesn't understand the difference between pass by value and pass by reference. If someone passing himself as an experienced C++ programmer fails to allocate memory with new and just throws mallocs around, the reaction would be the same.
> the term "a real python programmer" clearly meanys a developer who actually has used Python in the past in a remotely significant way
As a "real python programmer" that is trying to manage a conversion from Python 2 to 3, I can confirm that there is no superiority complex. We feel whipped and beaten, forced to convert a code-base that has been deemed "legacy" in exchange for a few nice string manipulation features that we don't really need.
A "real python programmer" in 2020 is an abandoned class.
As a "real python programmer" that is trying to manage a conversion from Python 2 to 3, I can confirm that there is no superiority complex. We feel whipped and beaten, forced to convert a code-base that has been deemed "legacy" in exchange for a few nice string manipulation features that we don't really need.
A "real python programmer" in 2020 is an abandoned class.
I use Python's comprehensions a lot (list, tuple/generator, set and dict). I would not ding someone for not using them. They're a tool, but not always the right tool.
Also, complex comprehensions can get out of hand and explicit loops become more legible.
I got dinged at a trading shop using C# for using Linq instead of hand-writing the loops. I wasnt given any constraints, just solve X problems. I also wasnt being paid for the test, so I solved the problems in the most expedient manner for me. I didnt get the job. So it goes...
Edit: I would ding someone claiming to be an experienced Python dev that cant identify/understand a comprehension. I've 16 years of experience with Python, so I know a fair amount (though the Python documentation is eternally open in my browser). I'm also the only person on my team with any real Python experience. We're building out extensive infrastructure in Python, so Ive been doing a lot of patient mentoring.
Also, complex comprehensions can get out of hand and explicit loops become more legible.
I got dinged at a trading shop using C# for using Linq instead of hand-writing the loops. I wasnt given any constraints, just solve X problems. I also wasnt being paid for the test, so I solved the problems in the most expedient manner for me. I didnt get the job. So it goes...
Edit: I would ding someone claiming to be an experienced Python dev that cant identify/understand a comprehension. I've 16 years of experience with Python, so I know a fair amount (though the Python documentation is eternally open in my browser). I'm also the only person on my team with any real Python experience. We're building out extensive infrastructure in Python, so Ive been doing a lot of patient mentoring.
So it's about you.
[deleted]
[deleted]
Everyone knew PEP 20 was feel-good baloney anyways. It just took the Python programmers a bit longer to come around.
During the coding exercise portion of an interview I let them choose any language they like. The exercise is exceptionally simple and doesn't push the boundaries of their language knowledge at all.
If somebody can't do the exercise in their language of choice I have doubts about their competency in general. That seems different than asking arbitrary questions about specific language constructs.
If somebody can't do the exercise in their language of choice I have doubts about their competency in general. That seems different than asking arbitrary questions about specific language constructs.
That's my Men In Black type of indirect interview screen. "In the language you're most comfortable with, implement xyz".
They then proceed to use the language that was listed on the job posting, that they're clearly barely familiar with, to answer the question. Typically incorrectly.
They then proceed to use the language that was listed on the job posting, that they're clearly barely familiar with, to answer the question. Typically incorrectly.
When I was interviewing devs, I rarely asked anyone to whiteboard. Instead, I came in with around a dozen small C++ apps. Id tell the candidate that unless told otherwise, the code compiles and links with default compiler settings (g++).
Id ask them to tell me the output (all of them would print some result). The examples were pretty small, most less than 20 lines, but each exposed understanding of the language. One they told me their output, always had them explain their reasoning and justification.
One of my favorites was:
I may have been a bit of a dock as an interviewer, but my goal was to get the candidate to say "I dont know". Wanted to make sure they wouldnt lie and try and bullshit. When I got the "I don't know", the followup was key: how,if, they would go about finding a solution. Being a dev isnt about knowing/memorizing everything, but effectively using research skills.
For the examples I provided that didnt compile, I always provided the error message(s), and then asked them to correct the program so it would compile.
Edit: formatting
Id ask them to tell me the output (all of them would print some result). The examples were pretty small, most less than 20 lines, but each exposed understanding of the language. One they told me their output, always had them explain their reasoning and justification.
One of my favorites was:
if (~false == true)
cout << "true";
else
cout << "false";
I may have been a bit of a dock as an interviewer, but my goal was to get the candidate to say "I dont know". Wanted to make sure they wouldnt lie and try and bullshit. When I got the "I don't know", the followup was key: how,if, they would go about finding a solution. Being a dev isnt about knowing/memorizing everything, but effectively using research skills.
For the examples I provided that didnt compile, I always provided the error message(s), and then asked them to correct the program so it would compile.
Edit: formatting
My response would be:
Doesn’t matter what the output is.. fire the person who wrote that code. If that’s what your codebase looks like, good luck finding and keeping people.
Also, yes bitops are nice and everything. But unless you’re creating games, or working on ffmpeg, you have no need for them except in certain fields to combine option for certain libraries
Doesn’t matter what the output is.. fire the person who wrote that code. If that’s what your codebase looks like, good luck finding and keeping people.
Also, yes bitops are nice and everything. But unless you’re creating games, or working on ffmpeg, you have no need for them except in certain fields to combine option for certain libraries
If someone writes a skill on a CV I expect it to be true. Before talking to prospective employees I ask them to submit code that they have worked on in private or professionally and once a guy sent me code from a tutorial that was easily googleable. He didn't get the job!
Lying on the CV is not proper and it's much better to write that you are a quick learner. I've hired people with little relevant experience but with a good brain.
It's like writing that you are fluent in a (human) language when you can barely scrape by with a greeting and goodbye.
Lying on the CV is not proper and it's much better to write that you are a quick learner. I've hired people with little relevant experience but with a good brain.
It's like writing that you are fluent in a (human) language when you can barely scrape by with a greeting and goodbye.
In my case (and in my recommendation), it's more like writing that you "know" a (human) language when you can get by with it conversationally in a foreign country, even if you couldn't go off and immediately write a novel in it, unimpeded, without a dictionary.
There are different definitions of "knowing" a language. I'm just arguing that the one that should be used on resumes is one of basic competency, not necessarily high expertise, unless you're specifically applying to be a specialist. That's not lying.
There are different definitions of "knowing" a language. I'm just arguing that the one that should be used on resumes is one of basic competency, not necessarily high expertise, unless you're specifically applying to be a specialist. That's not lying.
The positions I usually hire for are very specialised indeed, but I guess it's also comes down to cultural differences. In Norway you would usually specify at which level you know human and computer languages and it would be considered quite rude to put something on the CV that you only have a basic knowledge of. It gives off a feeling of "padding the CV" to appear better than it really is.
If someone writes that they know a (human) language without further specification I'd expect them to be able to speak and write it in a professional setting.
If someone writes that they know a (human) language without further specification I'd expect them to be able to speak and write it in a professional setting.
> That’s tough because often I’ve had coworkers who give their thumbs up or thumbs down based on “he had it on his resume and I asked him basic question X and he had no idea, terrible”.
I do that sometimes, if it's truly fundamental to the language/technology. For example, if someone lists C and clearly doesn't understand memory allocation/ownership well enough to append to a dynamically-allocated array, I'll say no hire. Likewise if someone lists SQL but can't do a join. Maybe if they were fantastic in some other way I'd let it slide but so far that's never happened...
Just don't put things on your resume if you don't know anything about them. It's not that hard. I get emphasizing something because you want to work with it more, but you should have worked with it _some_ first.
I do that sometimes, if it's truly fundamental to the language/technology. For example, if someone lists C and clearly doesn't understand memory allocation/ownership well enough to append to a dynamically-allocated array, I'll say no hire. Likewise if someone lists SQL but can't do a join. Maybe if they were fantastic in some other way I'd let it slide but so far that's never happened...
Just don't put things on your resume if you don't know anything about them. It's not that hard. I get emphasizing something because you want to work with it more, but you should have worked with it _some_ first.
I don't think I'd endorse this strategy. I've seen a few resumes mention Rust just because it's popular without actually knowing much about the language. If I see something on your resume I expect you to know it.
One of my personal projects was substantial enough (a dozen files or so) to encounter most of its main features, I've just never worked on a team with it, or shipped it in a product, and I know some but not all of the go-to libraries that everyone uses
I’m still learning Rust, but I’m developing a deeper appreciation for Go. I’ve already learned Go. As far as I can tell, I’m a Go expert.
Rust has a pretty large surface area. There’s a ton of places where you can get overwhelmed by choices. For example, when you’re working with slices, you might find yourself thinking about the pros and cons of different approaches using indexes, convenience functions, pattern matching, or iterators.
It’s a big toolbox, and sometimes I wish I had a smaller toolbox, even if it means giving up the choice of which tools to keep.
So, I’ll still be learning Rust for a while, too.
Rust has a pretty large surface area. There’s a ton of places where you can get overwhelmed by choices. For example, when you’re working with slices, you might find yourself thinking about the pros and cons of different approaches using indexes, convenience functions, pattern matching, or iterators.
It’s a big toolbox, and sometimes I wish I had a smaller toolbox, even if it means giving up the choice of which tools to keep.
So, I’ll still be learning Rust for a while, too.
Pretty much what I am thinking. When I use Rust, at the end of the day I will have spent more time with the language instead of my actual task, and I don't see this changing given the rate Rust is still changing. It feels like you have to be a "programming language afficionado" to use Rust properly.
Whereas in Go, there is always only one reasonable way to do a specific task. You almost forget about the language and just get stuff done.
Whereas in Go, there is always only one reasonable way to do a specific task. You almost forget about the language and just get stuff done.
[deleted]
That's why I was drawn to Python, and I still haven't found a good reason to switch to Go in my use cases.
If you don't care about performance, there's no reason to switch. Python is easy but it's very slow.
Python is only easy to write. Managing environments, dependencies, deployment, tooling, etc are all abysmal and Go gets very high marks in all of these areas (including ease-of-writing).
> If you don't care about performance
Or parallelism, or compiled binaries.
Or parallelism, or compiled binaries.
Here is a very practical example.
We chose Rust for the current project because our Python program took more than 1TB of RAM. Rust program carefully manually laying out memory takes 75G. Other choices in this case are C/C++, but after you get a hang of Rust, it's actually easier because you don't spend days inspecting core dumps in gdb: once it compiles it actually works.
We chose Rust for the current project because our Python program took more than 1TB of RAM. Rust program carefully manually laying out memory takes 75G. Other choices in this case are C/C++, but after you get a hang of Rust, it's actually easier because you don't spend days inspecting core dumps in gdb: once it compiles it actually works.
What kind of program requires that much ram?
> What kind of program requires that much ram?
Elasticsearch is written in Java, and routinely uses 30GB+ of RAM. I suspect if it was written in Python, it would use an order of magnitude more.
Elasticsearch is written in Java, and routinely uses 30GB+ of RAM. I suspect if it was written in Python, it would use an order of magnitude more.
I think you are confusing VM with RSS memory metrics. Elasticsearch is not using routinely 30GB+ of RAM, I am using it on machines that have a lot less RAM. You can additionally set how much RAM you want to give to JVM.
It would depend on the data set you want cached in memory I would think? And you set that in a configuration file I suppose. You can probably set it to use 128MB or RAM too.
An in-memory database essentially
They're not really the same thing, IMO. Sure, Go is pitched as a systems language, but when Google themselves are rewriting OS components written in Go with Rust, you know something is up. Go seems like Python++... a more reliable and performant high level language. The GC nature makes it inappropriate, IMO, for low-level systems work. Sure, write apps in it. Fine. But I can't see writing drivers in Go.
I’m not writing drivers or OS components. Services and command-line tools. Go has a bunch of stuff in standard library to make that easier. My experience is that these tools are a bit rougher to write in Rust, due to the additional decisions (which third-party libraries) I have to make wrt command line parsing, HTTP, etc. Rust’s ecosystem reminds me a bit of NPM or Haskell in that way. Go reminds me of Python in that the decisions are easier or have lower impact.
You could just pick the first option that looks good enough and be done with it so you avoid having to understand them all.
There has to be a learning strategy for kitchen sink languages though.
> So, yes, I am still learning Rust.
I have always been very cautious about how much I tout my skill with C++. Sure, I know a bunch. Probably a good bit more than the average bear. But the scope of C++ is enormous (even if you stop at C++03 there is a lot to know). And with new language standards it keeps growing.
Despite ~two decades of experience, I list my skill level with C++ as "intermediate" because "expert" paints a bullseye on your forehead. I could imagine tons of C++ questions that I could not answer off the top of my head. Those probably disqualify me as an expert and would involve a lot of embarrassing backpedaling in an interview.
I wonder how many times my resume was discarded because they needed someone with more than "intermediate" level experience with C++?
I have always been very cautious about how much I tout my skill with C++. Sure, I know a bunch. Probably a good bit more than the average bear. But the scope of C++ is enormous (even if you stop at C++03 there is a lot to know). And with new language standards it keeps growing.
Despite ~two decades of experience, I list my skill level with C++ as "intermediate" because "expert" paints a bullseye on your forehead. I could imagine tons of C++ questions that I could not answer off the top of my head. Those probably disqualify me as an expert and would involve a lot of embarrassing backpedaling in an interview.
I wonder how many times my resume was discarded because they needed someone with more than "intermediate" level experience with C++?
I don't remember which talk it was, but it was comparing an okay dev to a good dev; There was a slide where the "okay" dev rated their C++ knowledge as a 8 or 9, the "good" dev rating it as a 5 or a 6 and Bjarne Stroustrup rating it as a 7.
[edit]
Some googling later: https://www.slideshare.net/olvemaudal/deep-c/255
[edit]
Some googling later: https://www.slideshare.net/olvemaudal/deep-c/255
"The object does not know about it's functions"
That should be "its". Still, that's one way to force a fact into my brain...
That should be "its". Still, that's one way to force a fact into my brain...
The best thing that could have happened to you is to get interviewed in C (!!!) when then position is supposedly for C++, and eventually you learned from people that worked for that company, that they just wanted a WordPress webmaster LOL!
I'm not kidding, this is what happened to me 4 years ago.
Don't worry about your intermediate level.
For sure I can honestly say that I am more than honored to have a 'PhD' in C++'s "hello world" :D
It's a language that I would love to work on exclusively for the rest of my life, if I could get hired much like those stories we read about back in the early '90s.
They were hiring pretty much anyone who had an interest in computing, even if they were working on something completely unrelated to technology, and they were willing to train them.
The fun times...
I'm not kidding, this is what happened to me 4 years ago.
Don't worry about your intermediate level.
For sure I can honestly say that I am more than honored to have a 'PhD' in C++'s "hello world" :D
It's a language that I would love to work on exclusively for the rest of my life, if I could get hired much like those stories we read about back in the early '90s.
They were hiring pretty much anyone who had an interest in computing, even if they were working on something completely unrelated to technology, and they were willing to train them.
The fun times...
That sounds like a disaster employment situation for someone who actually wants to develop a career in C++. In what way is that a win?
It sometimes happens that any steady paycheck is a win.
Hope it never happens to you! But yes, it can happen.
Hope it never happens to you! But yes, it can happen.
"I wonder how many times my resume was discarded because they needed someone with more than "intermediate" level experience with C++?"
Don't be afraid to write "expert" with an ∗ with an explanation. You pass the initial screen and anyone hiring an "expert C++ programmer" who won't understand that caveat you gave just there is probably someone you don't want to work for anyhow....
Don't be afraid to write "expert" with an ∗ with an explanation. You pass the initial screen and anyone hiring an "expert C++ programmer" who won't understand that caveat you gave just there is probably someone you don't want to work for anyhow....
[deleted]
I wouldn't hesitate to place "Expert" on your resume if you feel you are exceedingly competent in many, but not all, areas.
No one should be expected to have rote memorization of all language, compiler and platform features. That is just a ridiculous standard (and I know many organizations interview against it regardless). But, if you are a true master of your craft, it should only take you a day or 2 to ramp up on one of the more esoteric areas of your skillset. A master can quickly swap hats, assuming they are all more-or-less the same brand. This is a point I would try to drive home during an interview if you feel the perception is slipping. "I haven't dabbled in [XYZ framework feature] lately, but I could probably pick it back up in a few days." If I were running the interview, that's all I'd need to hear to put my mind at ease.
No one should be expected to have rote memorization of all language, compiler and platform features. That is just a ridiculous standard (and I know many organizations interview against it regardless). But, if you are a true master of your craft, it should only take you a day or 2 to ramp up on one of the more esoteric areas of your skillset. A master can quickly swap hats, assuming they are all more-or-less the same brand. This is a point I would try to drive home during an interview if you feel the perception is slipping. "I haven't dabbled in [XYZ framework feature] lately, but I could probably pick it back up in a few days." If I were running the interview, that's all I'd need to hear to put my mind at ease.
I wonder how much this over-modest attitude of us continual learners is turning hiring into a market for lemons. That is, you are an "intermediate", but the overconfident person who's been doing C++ for two years and is touting themselves as an expert gets hired instead and you get to fix their disasters five years later.
And I bet this affects women and other minorities in tech disproportionately.
And I bet this affects women and other minorities in tech disproportionately.
I said I "knew C++" just yesterday and got a stern reply saying that I couldn't possibly know the language without writing production code for at least 10 years. And that's even though I've been very careful to never put C++ as something that I am more than "proficient" at. I doubt there is a single person alive who knows the entire C++ specification; I doubt there is even a compiler that fully implements the standard.
There's the now famous anecdote that even Stroustrup rates himself a 7/10 at C++ proficiency.
I've also worked on a handful of largeish (10k - 100k line) C++ projects both pre and post C++11, and also consider my C++ proficiency intermediate, even though I'm comfortable with the language and know how to fill in the gaps when I need to figure out something new, which now happens every 3 years.
The language is enormous and complicated, and most people will forget how some of the rarer intricacies work if they don't use them frequently. And since most features are very useful in a few situations, but are not widely useful enough to change daily programming habits, this is basically guaranteed.
The language is so big that intermediate is probably just the top of the scale now.
Rust isn't that big yet (although it is getting more complex), but many more of the concepts in Rust are somewhat unique to the language, so you're not just learning new syntax. I think the "always intermediate / always still learning" feeling happens earlier with Rust than with C++ because of this.
I've also worked on a handful of largeish (10k - 100k line) C++ projects both pre and post C++11, and also consider my C++ proficiency intermediate, even though I'm comfortable with the language and know how to fill in the gaps when I need to figure out something new, which now happens every 3 years.
The language is enormous and complicated, and most people will forget how some of the rarer intricacies work if they don't use them frequently. And since most features are very useful in a few situations, but are not widely useful enough to change daily programming habits, this is basically guaranteed.
The language is so big that intermediate is probably just the top of the scale now.
Rust isn't that big yet (although it is getting more complex), but many more of the concepts in Rust are somewhat unique to the language, so you're not just learning new syntax. I think the "always intermediate / always still learning" feeling happens earlier with Rust than with C++ because of this.
My story for discovering that skill is not a single metric was trying describe my c# some time ago, which I learned from a completely different side than most people:
- I've done heavily multithreaded network server running on mono/Linux
- I've implemented faster virtual method dispatch for a custom CIL compiler
- I've never touched popular .NET frameworks or GUI apps
Do I know lots about c#? yes. Would I pass a c# test for an average job? there's a good chance I wouldn't because I don't know "that thing everyone else uses".
I started listing languages in the "what did I achieve in that job" section rather than separate list.
- I've done heavily multithreaded network server running on mono/Linux
- I've implemented faster virtual method dispatch for a custom CIL compiler
- I've never touched popular .NET frameworks or GUI apps
Do I know lots about c#? yes. Would I pass a c# test for an average job? there's a good chance I wouldn't because I don't know "that thing everyone else uses".
I started listing languages in the "what did I achieve in that job" section rather than separate list.
Smart people who work in C++ already know this and aren't going to get on your case about it. It's a very diverse language in terms of common practices. There are many different accepted styles and many "time capsules" where particular language features were more or less fashionable in a time period, right up to the present. People can be opinionated about these things but shouldn't be judgemental.
OTOH it might be a good idea to understand a couple of the sub-cultures and their big ideas, and know that there are tradeoffs involved, with an open mind towards every set of practices.
OTOH it might be a good idea to understand a couple of the sub-cultures and their big ideas, and know that there are tradeoffs involved, with an open mind towards every set of practices.
I learnt clojure the language in a couple of hours.
Ofcourse, I am still learning the library and how to do things better in a functional way. But I was good to go with the language in a couple of hours.
Ofcourse, I am still learning the library and how to do things better in a functional way. But I was good to go with the language in a couple of hours.
And by writing Clojure, you lose a lot of type safety and compile-time efficiency. Not that that's a bad thing, just pointing out that there's a trade-off that it makes in favor of a simpler language to learn and implement. There's also the matter of it being more verbose to represent certain concepts in Clojure due to lack of syntax, but that's harder to argue.
> just pointing out that there's a trade-off that it makes in favor of a simpler language to learn and implement.
I am not sure thats a tradeoff, ruby and python didn't gain anything in terms 'lack of syntax' by trading off 'type safety and compile-time efficiency.'
I am not sure thats a tradeoff, ruby and python didn't gain anything in terms 'lack of syntax' by trading off 'type safety and compile-time efficiency.'
Learn, maybe. Implement, though? Pervasively-immutable data structures and STM were no walk in the park to write.
clojure's data structures are written in java
Interestingly ClojureScript's are self hosted: https://github.com/clojure/clojurescript/blob/master/src/mai...
The JVM Clojure story is probably just that the data sturcture implementations were done very early in the history of the language before all the type etc directives were there.
The JVM Clojure story is probably just that the data sturcture implementations were done very early in the history of the language before all the type etc directives were there.
they are indeed, what else would they be written in?
I'm having trouble connecting this with what I said...
I'm having trouble connecting this with what I said...
Me too, but I had already done SICP(scheme), without that I guess it would have take me much longer. Your background matters.
I don't think how you rate yourself should be based on the percentage of features and caveats that you know, it should be more based on how effective you are using it.
At my last job, we were trying to hire an expert C++ programmer, and every interview our C++ wizard would ask, "How do you rate your C++ knowledge on a scale of 1..10?" and pretty much invariably get a "8 or 9!" kind of answer.
Then came the C++11 and C++14 questions, and yeah, they didn't have a clue.
The guy they hired admitted that he wasn't a wizard, but said that he really wanted to become one.
Then came the C++11 and C++14 questions, and yeah, they didn't have a clue.
The guy they hired admitted that he wasn't a wizard, but said that he really wanted to become one.
This self-assessment ignorance phenomenon is well documented under the name Dunning-Kruger effect [1]
[1] https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effec...
[1] https://en.m.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effec...
> "How do you rate your C++ knowledge on a scale of 1..10?" and pretty much invariably get a "8 or 9!"
I'd guess that not even the members of the standard committee really know 90% of C++.
I'd guess that not even the members of the standard committee really know 90% of C++.
[deleted]
Rust is still new and shiny, and is still evolving at a rapid pace. Everyone's still learning Rust, I'd imagine that even Rust core contributors are still learning Rust! (The same can be said for most other languages too, although not all to the same extent). Anyone who is looking for Rust talent right now, and who discards the CVs of people "still learning", clearly knows nothing about Rust, nor about hiring good devs.
1.0 was released 5 years ago.
Swift is younger and I think it’s a great language.
If the tooling is ready and I don’t have to fight it, I’d be fine using Rust. I just need a reason. Anyone using it for iOS development?
Swift is younger and I think it’s a great language.
If the tooling is ready and I don’t have to fight it, I’d be fine using Rust. I just need a reason. Anyone using it for iOS development?
FullStory is - we have a shared core codebase in Rust, and then some OS-specific code for Android and iOS.
We're using a custom Rust toolchain so that we can support bitcode on iOS, but if you don't need that feature, then stable Rust works fine.
We're using a custom Rust toolchain so that we can support bitcode on iOS, but if you don't need that feature, then stable Rust works fine.
I love Rust, but it doesn't have a strong UI development story yet.
very few languages do, and those that do it is usually for just one platform.
Because native UI is on the decline unfortunately. Its too complicated and there are too many different systems. If you want a gui in rust you would be better off having your program start a web server on localhost.
Because most UI toolkits are strongly object oriented and Rust isn't an object oriented language.
My employer, Cloudflare, is using Rust as part of the 1.1.1.1 app on iOS.
Is this code shared across platforms?
Yes, it's also used on Android, mobile-wise, and tons of desktop platforms: https://github.com/cloudflare/boringtun#supported-platforms
I've actually got a working set of bindings to AppKit/UIKit that I'm trying to get to a release-able point. They run fine on both macOS and iOS; for the former I've also got decent support for sandboxed environments.
My goal is to write all my stuff in Rust, because I am sick and tired of writing products for the Apple ecosystem and then having to rewrite them if I want them outside of it.
I don't enjoy writing browser-wrapped applications (though they have their place, let me be clear...). I don't want to write in C just to be able to compile anywhere. IMO, Rust is the future.
/end fanboy-ism I suppose
My goal is to write all my stuff in Rust, because I am sick and tired of writing products for the Apple ecosystem and then having to rewrite them if I want them outside of it.
I don't enjoy writing browser-wrapped applications (though they have their place, let me be clear...). I don't want to write in C just to be able to compile anywhere. IMO, Rust is the future.
/end fanboy-ism I suppose
If you can share, how usable is your approach boilerplate/types wise? Would love to go all into Rust but the AppKit/etc. bindings get clunky very easily.
I've actually settled on an approach that feels just like writing Cocoa/AppKit/UIKit. It effectively exposes wrapper types that loop in delegates, so you wind up with a feeling like you're writing classes - you just can't subclass. I've tried to keep the conventions (entry points, lifecycles, method naming) very similar so knowledge transfer is there.
I have a repo for it but the example is pretty out of date. Can see about updating it when I've got the next push ready.
I have a repo for it but the example is pretty out of date. Can see about updating it when I've got the next push ready.
Will keep an eye out on your GitHub, just saw the repo you already have there. This is a heroic effort!
If you're interested, you can kinda see what I've been trending towards here: https://twitter.com/ryanmcgrath/status/1238285152771440640
The goal is to feel very, very familiar to anyone who's done Cocoa work before. :)
The goal is to feel very, very familiar to anyone who's done Cocoa work before. :)
It's very easy to cross-compile and use Rust as a library, leaving the Swift portion for display/views only. We are looking at doing this for our next app (OS X, but would work just as fine for iOS).
That long? I remember the launch parties...
I find this to be one of the reasons I didn't find rust that appealing as an C++ alternative. Its safety is something I admire and is highly valuable to many domains, but the two main things I want to abandon with C++ are its complexity and its compile times. Rust doesn't seem to get away from either of those.
As someone who doesn't really use Rust, does anyone who does find the complexity detracts from it a bit as a language? Is there effort to reduce complexity with the language or does it mostly embrace it?
At this point I find myself mostly looking at modern C alternatives—ones which manage to stay relatively simple the way C does, but with a few additional features and better designs (Zig, Odin, maybe Jai, etc).
All that said, I work with C++ and so I could see myself potentially working with Rust in the future, so I'm curious how people feel about its complexity, especially given that its complexity will presumably only increase with time.
As someone who doesn't really use Rust, does anyone who does find the complexity detracts from it a bit as a language? Is there effort to reduce complexity with the language or does it mostly embrace it?
At this point I find myself mostly looking at modern C alternatives—ones which manage to stay relatively simple the way C does, but with a few additional features and better designs (Zig, Odin, maybe Jai, etc).
All that said, I work with C++ and so I could see myself potentially working with Rust in the future, so I'm curious how people feel about its complexity, especially given that its complexity will presumably only increase with time.
From my perspective, Rust is a lot less complex than C++. It does still have a lot of features, but there are a couple of mitigating factors:
1. The features tend to be intuitive to use, and work in the way you expect them to. 2. If you do make a mistake, this tends to be a compile time error with a helpful error message that explains what you've done wrong. 3. The most complicated features are rarely used. Most of my Rust reads like TypeScript.
Part of the problem with C++'s complexity is not only is it difficult to work out the correct incantation, but it's difficult to know whether you have or not. Rust almost completely takes away that uncertainty.
The compile times are definitely an issue unfortunately.
1. The features tend to be intuitive to use, and work in the way you expect them to. 2. If you do make a mistake, this tends to be a compile time error with a helpful error message that explains what you've done wrong. 3. The most complicated features are rarely used. Most of my Rust reads like TypeScript.
Part of the problem with C++'s complexity is not only is it difficult to work out the correct incantation, but it's difficult to know whether you have or not. Rust almost completely takes away that uncertainty.
The compile times are definitely an issue unfortunately.
The problem is that there's no standard definition of "complexity," and so not only is it really hard to answer your question, it's also really hard to compare one language's complexity to another.
I personally subscribe to the "waterbed theory of complexity", that is, I believe that the world is complex, and often, attempts to remove complexity cause it to pop up somewhere else. Rust's goals have an inherent level of complexity to them, and so require a certain degree of complexity to accomplish. There is an argument that if we had dropped one or two of those goals, we could have made a language that is much simpler, but I'm also not sure Rust would be as popular if we did.
One thing we strive for with Rust is that features are reasonably orthogonal and work well together, without weird corner cases. We also try to only add more features when the cost is actually justified. We have said "no" to a lot of things. We have also tried and rejected a lot of things.
You also may enjoy this blog post of mine: https://words.steveklabnik.com/the-language-strangeness-budg...
(I should also note that I'm not actually on the lang team, so this is more of a statement about what I observe and my own opinion rather than policy, strictly speaking.)
I personally subscribe to the "waterbed theory of complexity", that is, I believe that the world is complex, and often, attempts to remove complexity cause it to pop up somewhere else. Rust's goals have an inherent level of complexity to them, and so require a certain degree of complexity to accomplish. There is an argument that if we had dropped one or two of those goals, we could have made a language that is much simpler, but I'm also not sure Rust would be as popular if we did.
One thing we strive for with Rust is that features are reasonably orthogonal and work well together, without weird corner cases. We also try to only add more features when the cost is actually justified. We have said "no" to a lot of things. We have also tried and rejected a lot of things.
You also may enjoy this blog post of mine: https://words.steveklabnik.com/the-language-strangeness-budg...
(I should also note that I'm not actually on the lang team, so this is more of a statement about what I observe and my own opinion rather than policy, strictly speaking.)
> attempts to remove complexity cause it to pop up somewhere else
Yes, but sometimes the average brain is better at dealing with certain types of complexity. C++, IMO, puts the complexity in the wrong places. Programming is inherently complex, but it shouldn't be any more so than it needs to be and the complexity should be of the type humans can manage, as much as possible anyway.
Yes, but sometimes the average brain is better at dealing with certain types of complexity. C++, IMO, puts the complexity in the wrong places. Programming is inherently complex, but it shouldn't be any more so than it needs to be and the complexity should be of the type humans can manage, as much as possible anyway.
I don't disagree! Well, I might disagree that they put it in the "wrong" place exactly; I think that the committee is doing the best that they can given their goals and constraints. I do not have the same goals and constraints, and therefore prefer to use other languages.
> Is there effort to reduce complexity with the language or does it mostly embrace it?
You're right that it isn't a "simple" language (in the Rich Hickey sense of the word). And I don't think there's any effort to actively simplify it.
However, I do expect the rate of complexity growth to taper off fairly soon. Every feature that gets added to Rust is added carefully and with a clear vision in mind. Up until now they've still been building out the foundations of what most people will need when using Rust in different contexts. Recently a lot of this has been ergonomics (like async/await). But I think the rate of features being added is an S-curve, and I think we're nearing the top. Given that, I have hope that it won't follow the same path as C++ in terms of sprawl; it's certainly not as complicated as C++ yet, and if it doesn't keep growing at this rate, I don't think it will become that way.
Part of why C++ is so complicated is that it's had to tack-on decades of language advancements, after the fact, as they were invented/became prevalent. Heck, C++ itself is already a tack-on of C. There wasn't a clear initial vision for the past couple decades of "stuff".
Rust, on the other hand, a) has those decades of ideas to incorporate from the outset in a cohesive way, and b) was started from scratch, not an extension of an existing language. This has so far meant a much clearer sense of vision and big-picture design. These features were made to work together; the roadmap was fairly clear from the beginning.
You're right that it isn't a "simple" language (in the Rich Hickey sense of the word). And I don't think there's any effort to actively simplify it.
However, I do expect the rate of complexity growth to taper off fairly soon. Every feature that gets added to Rust is added carefully and with a clear vision in mind. Up until now they've still been building out the foundations of what most people will need when using Rust in different contexts. Recently a lot of this has been ergonomics (like async/await). But I think the rate of features being added is an S-curve, and I think we're nearing the top. Given that, I have hope that it won't follow the same path as C++ in terms of sprawl; it's certainly not as complicated as C++ yet, and if it doesn't keep growing at this rate, I don't think it will become that way.
Part of why C++ is so complicated is that it's had to tack-on decades of language advancements, after the fact, as they were invented/became prevalent. Heck, C++ itself is already a tack-on of C. There wasn't a clear initial vision for the past couple decades of "stuff".
Rust, on the other hand, a) has those decades of ideas to incorporate from the outset in a cohesive way, and b) was started from scratch, not an extension of an existing language. This has so far meant a much clearer sense of vision and big-picture design. These features were made to work together; the roadmap was fairly clear from the beginning.
This. Exactly. Also, there is definitely an ongoing effort to make the language simpler, not in the type system which arguably is getting more complex, but in the way the borrow checker is getting smarter. Might be imperceptible at first but really brings a lot in term of ergonomics and productivity.
Simplifying the borrow checker is a slightly different question than simplifying "the language" (meaning the syntax and/or behavior of the syntax), because the latter can break backwards-compatibility (which is why it likely won't happen).
But the borrow checker is an interesting case because simplifying its rules in such a way that they're more tolerant (without sacrificing safety) might reduce cognitive overhead while still being fully backwards-compatible.
But the borrow checker is an interesting case because simplifying its rules in such a way that they're more tolerant (without sacrificing safety) might reduce cognitive overhead while still being fully backwards-compatible.
The thing is, in some sense, the borrow checker got more complex. But because it accepts more programs, it makes programming in Rust feel less compex. This is related to the waterbed stuff I was talking about elsewhere in the thread.
There is a fine balance here, for example: https://news.ycombinator.com/item?id=22465409
There is a fine balance here, for example: https://news.ycombinator.com/item?id=22465409
Yeah ! That's was the point I was trying to make. It was a breath of fresh air when I switched from Rust 2015 to Rust 2018, without obvious change in the language from my point of view.
Rust is not a complex language; it's otherwise: Rust has higher-level abstractions that makes it much easier to program with.
Actually, I was trying to explain this a few days ago: https://users.rust-lang.org/t/any-possible-improvements-to-t...
Rust has an Iterator type. It might be a bit "complex" to understand at first sight, but once you grasp the concept, it makes programming much easier. And your code is much more readable too. I try to avoid loops/conditionals these days; if I'm using them, I probably can express that in a Type and have a descriptive name/functions for that type.
There are many more types/syntax that makes programming with Rust a marvel: Result/Option types, generics, macros, async/await, error chaining, etc...
Actually, I was trying to explain this a few days ago: https://users.rust-lang.org/t/any-possible-improvements-to-t...
Rust has an Iterator type. It might be a bit "complex" to understand at first sight, but once you grasp the concept, it makes programming much easier. And your code is much more readable too. I try to avoid loops/conditionals these days; if I'm using them, I probably can express that in a Type and have a descriptive name/functions for that type.
There are many more types/syntax that makes programming with Rust a marvel: Result/Option types, generics, macros, async/await, error chaining, etc...
I write Rust as my day job and I still consider it a complex language. There's a lot of non trivial things encoded in the type system. Send/Sync, Pin, async/await, object safety, borrowing, ownership, I could go on.
It's also pretty different to what most people are used to. I found it a approach to polymorphism refreshing, coming from Haskell, but that's not a typical pathway. The average Java dev will need some time to get used to how extensive generics are in the language.
It's also pretty different to what most people are used to. I found it a approach to polymorphism refreshing, coming from Haskell, but that's not a typical pathway. The average Java dev will need some time to get used to how extensive generics are in the language.
I find that I rarely touch the most complicated parts. Sure, it has a rich type system with all kinds of magic you can do with generics and such, but if you’re just making an application you often don’t have to futz with it. You can also often get away without even providing a type. If you’re working on deep data structures and libraries it gets more complicated, as it should. It’s a language that allows you to specify the behavior of your program quite precisely, and in many cases you don’t have to worry much. Little things like allowing a clone here or there when it isn’t a tight loop go a long way towards simplicity.
A little weird that you didn't mention Go, which seems to fall exactly in the category of "a simple, modern, well-designed C"
I am researching a backend programming language for a future project. I am debating if I should choose rust fearing for the difficulty of hiring.
Why not Go? There will be minimal friction to doing most backend work, and the standard library has most things you'd need built in. If you have any questions, feel free to hit me up!
I think that you'll actually attract all the right people.
But we need to control the burning rate. (We are a startup) the right people are expensive.
Hire remotely.
We are all always learning. I am all over the place from java, shell, awk, python, and now I'm playing with Go and I kind of like it but can't find the time to actually make something useful so I can learn from it.
I don’t consider this a positive.
I would, on balance, prefer to have a language with a smaller feature set that limits the amount of syntactic variability in the code I see. This, I believe, allows me to focus on the problem, not on the language features the person is using to solve the problem.
With Rust it always feels like there are changes and, at times it feels exhausting having to ‘keep up’. It also means that there’s high variability in the code you see in the wild.
I would, on balance, prefer to have a language with a smaller feature set that limits the amount of syntactic variability in the code I see. This, I believe, allows me to focus on the problem, not on the language features the person is using to solve the problem.
With Rust it always feels like there are changes and, at times it feels exhausting having to ‘keep up’. It also means that there’s high variability in the code you see in the wild.
It's like C++ - no-one can ever know it all.
This is applicable to any language with a sufficiently big ecosystem, but the thought is sound.
Rust is a terrible language. It has an identity crisis. Thinks it's a high level but also system level language. You cant be both. The unix philosophy always wins. Do one thing well. C is the perfect system lang and Java/C#/Lisp/Python etc are the cream of high level langs.
Rust has always clearly labelled itself as first and foremost a systems programming language. It strictly maintains performance and safety as its top priorities. It doesn't go out of its way to be easy to learn or to use, compared with higher level languages. Doesn't seem to me like there's any identity crisis.
Why can't you be both? The "high level" features rust offers to make it feel like a modern language are just abstractions, nothing that makes it directly inferior to C. Allowing for modern constructs without sacrificing performance is a good thing.
Then I started only listing the ones I knew the best.
Now what I do is treat the list as aspirational. "Here are the technologies that I'd like to work with (and which I'm familiar enough with that I could figure the rest out on a job)." I try to paint a story with those technologies: this combination of technologies draws an outline around the type of work I want to be doing.
I did this recently with Rust on the list even though I've only done a couple of personal projects with it, and the presence of it specifically made me stand out to a company that I'll soon be starting a position at! They use Rust and are sort of a dream job in a couple other ways too. They said the presence of that language spoke to the personality of the developer, and the kind of things he was likely interested in.
Takeaways: don't undersell yourself, and tell a coherent story.
Edit: To be clear, I was not being deceptive. Through the interview process the company learned precisely how well I know the things that I listed - we even dove into some of my projects together - and they were still excited to hire me. My point is that "knowing general principles" + "being fairly comfortable in a particular language" is often all that's really being asked for, and doesn't need to be disqualified with "still learning" just because you don't know everything there is to know.