Hacker News new | past | comments | ask | show | jobs | submit login

I’ve been working primarily in .NET the last five years, and have been transitioning to Rust professionally the last few years.

For some reason, people act like being a C# or Java dev means that you’re an idiot. If you’re skilled enough to be writing quality high-performance code in those languages, learning Rust is not a huge barrier…




I agree with you: learning a new language, sometimes in the heat of the moment without even knowing the language existed before, is a thing skilled software developers are able to do remarkably quickly, even if they haven't specially gone out of their way to train for that skill, as, in the real world, you end up dealing with so many different languages--as a C#/Java developer you probably also have had to work with SQL, either bash or PowerShell, can't really avoid JavaScript, likely had to drop to C/C++ at some point to build a way to access a "legacy" component--that it is very difficult to avoid having the right generalizations happen accidentally in your brain.

But, I work with a lot of college students who are just beginning to learn software development, and the realization that that kind of generalization is possible is not obvious; and a lot of people who are only a few years into their career--but maybe think they are pretty damned good at it (I look back at myself when I had a mere 10 years of actual-real-world experience and think just how much I still had to learn to become who I am today... I am thankful I worked with some gods and always knew I had a long way to go)--not only have a hard time learning a new language (I remember when I was in high school trying to learn Pascal after I had spent years coding in Visual Basic and even getting paid to do so, and thinking I knew C... I did not ;P) but internalize how daunting it is and then go really far out of their way to avoid learning new languages (which, thankfully, I could not as high schools at the time were ping through a big upset in curriculums and so we learned a new language every year for a while and I got recruited to help my AP Computer Science teacher as he also was having to adjust way too quickly through Pascal, C/C++, and Java/JavaScript).

And it is actually quite remarkable how well people manage to do at this, using IDEs to avoid command lines and ORM technology and DSL compilers to avoid having to use SQL or other languages, they glom onto whatever ridiculous interop mechanism they can that prevents them from learning about low-level languages... and I think it really does hurt them, and I remember running into some software developers who did so well that they never managed to get to the right generalizations and they are now old and can still only program in one language (the same way I have a really really really hard time speaking in any language other than English); but like, most developers, no matter how hard they try, eventually do get enough exposure to enough at least slightly-different languages to get this skill (which is, when I get hired to teach courses, what I try to accelerate: Comparative Machine Language Morphology ;P).

But like, due to us all living in the Eternal September--and I do not just mean online: I was shocked recently when I learned how many CS students there are at most of the other Universities (it turns out the one I still live at is an extreme minority with only a few percent of the population being Computer Science and only half the students being engineering at all)--not only are we going to end up interacting directly with a number of people who actually do find learning new languages hard (and think it must fundamentally be hard for everyone forever), but I think we are going to run into a lot of managers on the front lines of trying to build businesses out of cogs (a practice I dislike on a number of grounds, but fully admit, if you can pull it off, is probably an extremely powerful and efficient way to do industrial/corporate engineering) who are also extremely resigned to the notion that the early-stage people they hire are oft incapable of learning new languages quickly enough to truly be a usable cog, as like... do they really even want to hire someone who has as much experience as you must (as the way you worded your comment implies you've been coding a lot longer than the mere 5 years you have been coding in Java/C# ;P).


> using IDEs to avoid command lines and ORM technology and DSL compilers to avoid having to use SQL or other languages

IDEs, ORMs and other tools have their roles. They didn't get invented just because people are lazy and don't want to learn "command line" and SQL.

If you didn't have the occasion to experiences use cases where such tools are useful, that doesn't mean they aren't useful.

Otherwise you can argue that compilers are for people who are too lazy to write machine code directly.


I can appreciate why my statement there might seem overly dismissive if you want to get particularly defensive; but I'm commenting on people, not technology, and I've met/seen quite a number of developers who rush to and relish these technologies to actively avoid learning languages, and list such as their primary reason for their use.


Somehow I’ve started to become one of the older people in the room at work, I don’t know how that happened so suddenly :p


This happened to me when I turned 30. I was like "wait... I'm not the young person anymore. Most of the people here are younger than me"...

Now I'm 41 and it's weird to be working with 21 year olds. Not bad but you just have these funny cultural differences.


> I agree with you: learning a new language, sometimes in the heat of the moment without even knowing the language existed before, is a thing skilled software developers are able to do remarkably quickly

Maybe it is true, for some people and for some languages.

However, learning the syntax of a new language means nothing if you don't already learn libraries, tools, frameworks, tools, patterns, idioms. And that still takes time.

Memory isn't unlimited and while you learn new concepts, try to make room for new concepts, you start to forget some of the old concepts, especially if you start using them less frequently or seldom use them.


So, what I try to teach in my Comparative Machine Language Morphology course is the skill of being able to go from nothing to expert in a technology almost immediately by trying to get your brain to generalize into what we know about how humans conceptualize algorithms.

To tell a quick anecdote: when Apple announced Swift, I was hearing about it for the first time in the audience at WWDC during the keynote. As I watched, it was quite clear to me that this was a language that was mixing parts of Scala, Haskell, and (awkwardly enough) Ruby with the background of Objective-C, and it just immediately clicked. I ended up giving a talk about the language a few days later at AltConf.

The reality is that, unless people go extremely far out of their way to push their language in a way that makes it awkward for the user--I had a student who designed an esolang based on gravity and "roadrunner physics" where the code was a map where things didn't start to fall until they had some kind of interaction--there is very little "new" under the sun: the vast majority of "advances" in programming languages were already pioneered many decades ago.

(The most ridiculously-obvious example of this is probably Go, which has almost nothing that wasn't already understood by the 1970s, including its mechanisms around channel-oriented concurrency. There is an amazing article that attempts to compare Go to a "Brand X" language that turns out to be Algol 68. But like, Rust's entire schtick--the reason it is called Rust!--is because they actively refused to do any new language research and instead based it all on well-worn concepts, and yet people still whine about it incessantly merely because they haven't put anywhere near enough time into learning about the history of programming.)


Do you have any materials about your course online?


Still, going from C# or Go to Rust means a productivity hit.


There is a learning tax at the beginning, for sure, but this is a fixed cost. We experience that once this first hump is passed, the code and output quality is higher, and the cloud resource cost decreases significantly.

Now the challenge is to hire new developers that are not familiar with Rust; it would take a month or so for them to be productive (assuming robust internal code practice). But, well worthwhile in our opinion, as least for greenfield application/services.

(We are coming from Java / nodejs/TS)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: