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

Rust in Large Organizations

gist.github.com

Post reply on HN
Print view View original

11–20 of 51 posts

Re: Rust in Large Organizations

#11

Post by vlovich123 »

awestroke wrote: post #2

Super interesting read. The geometric growth of deps problem seems like a natural consequence of having a good package manager. In languages like C/C++, libraries often include all their code - there are no transitive dependencies.

My reading of that isn't that the problem is the large set of transitive deps but that it's opaque to the native build system at these companies (Buck/blaze) which means rebuilding one requires rebuilding all which is time-consuming. I infer this from the discussion about being able to query inputs/outputs of the build so that integration can be done more meaningfully into these systems to rebuild just changes.

Re: Rust in Large Organizations

#12

Post by nirvdrum »

ausjke wrote: post #6

I tried to learn those languages, my IQ level can handle java/golang/python/c just fine, but c++ and rust is beyond my comfort zone for sure, for c++, getting familiar with it is OK, but getting good at it is hard, really hard, mastering it is impossible for me. similar can be said to rust as far as I can tell. even python has some "tricks", try "x=256; y=256; x is y" and "x=257, y=257, x is y" under python, or 'x=[]…

I love high-level languages and think they've had a great democratizing effect that lets people across a wide array of backgrounds be reasonably productive without a ton of background knowledge. But, the underlying computer isn't magic. In many ways, it's pretty dumb. I suspect if you spent a bit of time looking at a system architecture, a lot of things would click into place.

Early in studies, I couldn't really wrap my head around pointers. I mean, I knew what they were and how I needed to work with them, but they just seemed like a weird abstraction. A short intro to assembly and later on, a computer architecture class, cleared that all up.

Everyone learns differently, so my experience likely isn't applicable. But, for me, no longer treating the CPU as a black box helped me get a much better mental model of lower-level languages. And I think I'm a better high-level developer for it.

Re: Rust in Large Organizations

#13

Post by ausjke »

nirvdrum wrote: post #12
ausjke wrote: post #6

I tried to learn those languages, my IQ level can handle java/golang/python/c just fine, but c++ and rust is beyond my comfort zone for sure, for c++, getting familiar with it is OK, but getting good at it is hard, really hard, mastering it is impossible for me. similar can be said to rust as far as I can tell. even python has some "tricks", try "x=256; y=256; x is y" and "x=257, y=257, x is y" under python, or 'x=[]…

I love high-level languages and think they've had a great democratizing effect that lets people across a wide array of backgrounds be reasonably productive without a ton of background knowledge. But, the underlying computer isn't magic. In many ways, it's pretty dumb. I suspect if you spent a bit of time looking at a system architecture, a lot of things would click into place. Early in studies, I couldn't really wrap…

not the case for me, my background is in EE and cpu architecture, and I know hardware better than software actually...

Re: Rust in Large Organizations

#15

Post by mmastrac »

Glad to see some thinking going on in this area. We're using Rust at FullStory and it's about 1/3 source-wise for one of our projects. A few of these concerns echo conversations that teammates have had on Slack.

FullStory itself is somewhat polyglot (Go on the server, TypeScript/react in the browser, Java/ObjJ/Rust on native mobile) and we've felt some of the pain around having a consistent and reliable build environment. We've also had internal discussions along these lines - ie: which deps can we trust from various package managers (npm has interesting arbitrary code execution as well!).

Building tooling to manage all these languages in a common system is a _huge_ commitment. We're actively hiring for the role of productivity engineers which is something that I see becoming more important in orgs as they scale up, the same way that devops/SRE split out in the 2000s.

Re: Rust in Large Organizations

#17

Post by gridspy »

ausjke wrote: post #13
nirvdrum wrote: post #12

Earlier quoted context omitted.

I love high-level languages and think they've had a great democratizing effect that lets people across a wide array of backgrounds be reasonably productive without a ton of background knowledge. But, the underlying computer isn't magic. In many ways, it's pretty dumb. I suspect if you spent a bit of time looking at a system architecture, a lot of things would click into place. Early in studies, I couldn't really wrap…

not the case for me, my background is in EE and cpu architecture, and I know hardware better than software actually...

Relating to the "Python Tricks" you mention, remember that "is" means "these two pointers (x & y) point to the same place".

You should never be to surprised when you create a bunch of new values and a language like python isn't "smart" enough to say "these are all the same value, so I'll create one of those and have x, y, etc all point to the same thing."

Re: Rust in Large Organizations

#18

Post by gridspy »

ausjke wrote: post #10
kbp wrote: post #7

Earlier quoted context omitted.

I don't think that's a great example for Python; that's just knowing what "is" is for. The fact that it works the same as == for small integers in CPython is an optimisation showing through, but only in a place where it doesn't really matter. You still need to have a grasp on the difference between reference equality and value equality without getting into anything anyone would call tricks or implementation details (…

x=x.append(1) and guess what, now x is "None", yes it makes perfect sense for those who coded python for a while, but it's a disaster for newcomers. too many similar demos by the way I actually like python and use it often, just saying it can surprise you when you start, not intuitive per se until you become good at it.

Sure, x.append doesn't return a value. So x=x.append is None. You learn that one pretty quick.

Perhaps use x = x + [1] instead?

But yeah, surprises like this (unexpected return values) are actually a pretty strong case for using a language like Rust or C++ where the compiler will tell you this before you run the program.

Re: Rust in Large Organizations

#20

Post by coldtea »

ausjke wrote: post #6

I tried to learn those languages, my IQ level can handle java/golang/python/c just fine, but c++ and rust is beyond my comfort zone for sure, for c++, getting familiar with it is OK, but getting good at it is hard, really hard, mastering it is impossible for me. similar can be said to rust as far as I can tell. even python has some "tricks", try "x=256; y=256; x is y" and "x=257, y=257, x is y" under python, or 'x=[]…

>even python has some "tricks", try "x=256; y=256; x is y" and "x=257, y=257, x is y" under python, or 'x=[], y=[], x is y; x=y=[], x is y' you will know what I mean, you actually need know some internal designs to use python properly.

Or don't compare numbers with "is", since you're not supposed to? Then you can remain oblivious to the underlying mechanics that break "is" comparison for larger integers...

Post reply on HN