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

31–40 of 51 posts

Re: Rust in Large Organizations

#31

Post by kbp »

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

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

I believe they're still object pointers in CPython, they're just ordinary singletons; in other implementations, they aren't even singletons. Python's object model doesn't have primitives. Adding special rules around them would significantly complicate the language as well as limit the implementors' ability to fiddle with the ranges of pre-allocated instances, for minimal benefit.

Re: Rust in Large Organizations

#32

Post by [deleted] »

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…

[deleted]

Re: Rust in Large Organizations

#33

Post by kccqzy »

monocasa wrote: post #5
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.

A slight difference is that Rust really wants to be the top level compiler. More than a lot of languages, even C++, it really relies on link time optimization to get the perf you'd expect.

In that case just print the command line cargo would've used to do the linking and let a different consume that and make changes. That's an easy case.

Re: Rust in Large Organizations

#34

Post by hope-striker »

monocasa wrote: post #5
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.

A slight difference is that Rust really wants to be the top level compiler. More than a lot of languages, even C++, it really relies on link time optimization to get the perf you'd expect.

How this is more true of Rust than modern C++?

Re: Rust in Large Organizations

#35

Post by hope-striker »

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

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

Integers are object pointers, too. CPython just so happens to preallocate a range of small integers[0].

[0]: https://github.com/python/cpython/blob/master/Objects/longob...

Re: Rust in Large Organizations

#36

Post by hope-striker »

coldtea wrote: post #20
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...

Yep, this is totally implementation-defined behavior, so it's actually kind of harmful to think that you should "know some internal designs" here.

Re: Rust in Large Organizations

#38

Post by mijoharas »

lacker wrote: post #14

I was entertained by this exchange: ms: would like to know how to control use of unsafe in codebase google: grep

As I got to that point I started laughing and then explained it to a non-programmer that was with me.

My fumbled metaphor of "Find in page across a lot of pages" didn't really land...

Re: Rust in Large Organizations

#39

Post by paulddraper »

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…

For a modern make, I recommend checking out https://bazel.build/ (or its offspring Buck and Pants).

It's mentioned in the writeup.

Re: Rust in Large Organizations

#40

Post by nunchuckninja »

Can any rust experts tell me that unsafe rust is powerful and expressive enough to let me do anything?

I have a use case where I have two iterators on a linked list in nested loops and the second iterators deletes some elements as it goes. Is this something I can express in unsafe rust?

Post reply on HN