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

21–30 of 51 posts

Re: Rust in Large Organizations

#21

Post by coldtea »

kbp wrote: post #7
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 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 (…

>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.

Python should have prevented checking primitives with is though -- only let object pointers...

Re: Rust in Large Organizations

#23

Post by kelnos »

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 think you just need to give yourself some time. C++ is a large enough language now that "mastering" it will likely take several years of daily/professional use. I used to be decent at C++ (in the early/mid 00s), but given that I haven't touched it since then, I'm completely lost as to current best practice. If I wanted to, I'd have to spend many months catching up to all the changes in the language since I last used it.

Rust has a much smaller surface area, but does have some unique things to understand like the borrowing and lifetimes. The good thing is that as the borrow and lifetime checkers in the compiler get smarter, the less you have to know about those things while writing plain-jane code.

You mention downthread that you have an EE/comp-arch background. I do as well, and have found that useful on occasion when working on embedded systems, but perhaps not a huge asset when dealing with language esoterica. Sure, perhaps understanding pointers and memory access is easier when you understand how memory actually works, but it'll only get you so far.

Re: Rust in Large Organizations

#24

Post by heavenlyblue »

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.

>> yes it makes perfect sense for those who coded python for a while, but it's a disaster for newcomers.

It’s a disaster for newcomers to programming in general. I am pretty sure a seasoned developer in any other language would understand why that returns None, too.

Re: Rust in Large Organizations

#25

Post by [deleted] »

gridspy wrote: post #17
ausjke wrote: post #13

Earlier quoted context omitted.

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."

[deleted]

Re: Rust in Large Organizations

#26

Post by ausjke »

gridspy wrote: post #18
ausjke wrote: post #10

Earlier quoted context omitted.

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.

x=1; id(x); x+=1; id(x); # different id, means x points to new location

x=[1,2],id(x), x+=[3], id(x) ; # same id, means x stay at the original location

there should be a blog page to list those surprises for beginners :)

Re: Rust in Large Organizations

#27

Post by epage »

est31 wrote: post #9

It's interesting how many organizations had problems with build.rs. Other build systems like Make, scons, or autotools have the ability to run arbitrary things in any step in the process compared to Rust which has a clear separation. There is a proposed RFC to reduce the need for build.rs scripts in many cases [1], will likely be merged within the next 2 weeks. [1]: https://github.com/rust-lang/rfcs/pull/2523

For code-gen, I'm experimenting with checking in the results and having a "is the code-gen correct" check in the CI

See https://github.com/crate-ci/imperative/pull/4 for an example

I hadn't even considered the benefit of reducing build.rs usage. I was focused on speeding up people's builds by reducing the number of dependencies involved and making my crate do less work when being built.

Tempted to turn this pattern into a crate to reduce the hump to overcome to adopt it.

Re: Rust in Large Organizations

#28

Post by saghm »

est31 wrote: post #9

It's interesting how many organizations had problems with build.rs. Other build systems like Make, scons, or autotools have the ability to run arbitrary things in any step in the process compared to Rust which has a clear separation. There is a proposed RFC to reduce the need for build.rs scripts in many cases [1], will likely be merged within the next 2 weeks. [1]: https://github.com/rust-lang/rfcs/pull/2523

> It's interesting how many organizations had problems with build.rs. Other build systems like Make, scons, or autotools have the ability to run arbitrary things in any step in the process compared to Rust which has a clear separation.

I think the history behind this is that Cargo was built with only Rust in mind; when your world is 100% Rust, you generally don't need much extensibility in your build process. Make, scons, and autotools all seem like they were designed to be more language agnostic from the start. It'll be interesting to see how cargo needs to evolve to be able to support interior with other ecosystems at the level that larger companies need.

Re: Rust in Large Organizations

#29

Post by ChrisSD »

saghm wrote: post #28
est31 wrote: post #9

It's interesting how many organizations had problems with build.rs. Other build systems like Make, scons, or autotools have the ability to run arbitrary things in any step in the process compared to Rust which has a clear separation. There is a proposed RFC to reduce the need for build.rs scripts in many cases [1], will likely be merged within the next 2 weeks. [1]: https://github.com/rust-lang/rfcs/pull/2523

> It's interesting how many organizations had problems with build.rs. Other build systems like Make, scons, or autotools have the ability to run arbitrary things in any step in the process compared to Rust which has a clear separation. I think the history behind this is that Cargo was built with only Rust in mind; when your world is 100% Rust, you generally don't need much extensibility in your build process. Make, s…

The way I heard it was that Cargo was intentionally avoiding being a complete build system. The idea being that Make et al would still be used when necessary so build.rs (and cargo in general) could be free to concentrate on managing the Rust parts exclusively.

Re: Rust in Large Organizations

#30

Post by bsder »

kccqzy wrote: post #3

The build system issue isn't inherent to Rust or to large organizations. Even in a startup, we have a polyglot development with a separate build tool in addition to the language-specific build tool. We ended up doing much of the same things: use the language-specific build tool to generate artifacts which are then consumed by the normal build tool.

> The build system issue isn't inherent to Rust or to large organizations.

That may be true, but even the big boys can't converge, and they all have their own build systems.

Attempting to add/remove features from cargo/rust when even the big companies can't agree as to what is most important in a build system seems like a path to disaster.

The big boys aren't always right (see: Gradle/Groovy).

Post reply on HN