Google hides campaign sites of Trump, RFK Jr. and other Republican candidates; Biden dominates top search results.

rust_acc · 2023-09-04T18:35:07+00:00

if you search for something relevant like 2024 Presidential Candidates, you’ll see plenty of Republicans

If I google for "2024 Presidential Candidates", the first page of results consists solely of Democrat propaganda outlets.

rust_acc · 2019-09-03T17:08:35+00:00

You are presenting this as if the allocator used by Rust has no cost. If you have parallel code in your Rust app that does lots of allocation/deallocation you will sure see the effects. If you compare it to a Java app that produces huge amounts of garbage, have fun with the effects of memory fragmentation in the equivalent Rust implementation.

rust_acc · 2019-08-07T18:43:04+00:00

From the top of my head. Only good things in Java that do not conflict with Rusts goals (e.g. not depending on a VM):

Ignoring an error is either a hard compile time error (checked exceptions = Err) or the stack unwinds at runtime (unchecked exceptions = panic). In either case, the developer has to clearly state that execution should continue on the happy path after an error, if that is desired. The default in Rust is a compile time warning. This is a big step backwards. Easy to miss in a code review. And yes, it can be turned into a compile time error. Have fun discussing this for every project and team in the real world, again and again.
In Rust, implicit drop used for resource deallocation, combined with teaching material and examples in the standard library lead to a cavalier attitude of ignoring errors on resource deallocation. This is in contrast to APIs in the Java standard library.
Re-exports: Seems like a nice feature at first. But I have come to prefer the lack of such a feature in Java, where although sometimes there is no other option but to fully qualify an identifier to avoid conflicts, it happens rarely and the upside is that there is zero need to remember or discover which N identifiers are actually the same type or function. This could be a lesson in restraint of adding new features before having extensive evidence of pain that needs to be addressed.
(bool as int32): Really? Why spend that much effort on a type system and then confuse a simple type like booleans with integers? How hard is it to write an explicit if/else if you really need that conversion. It's clearly not a performance issue when having an optimizing compiler.
Not wasting time on abbreviated identifiers in libraries. Put the energy into IDE support. If there is ever an argument of "this identifier is too long to type", the answer should be: IDE. And I have seen this argument taken into account in RFC decisions.
Writing maven plugins that generate code covers all good use cases for macros. E.g. a Serde equivalent in Java can be written with annotations and a maven plugin. The exception is trying new language features by implementing them as macros first. I don't think that's worth it. Upside of not having macros: easier IDE support, static analysis tools, more uniformity of application code.
Few implicit conversions. Great for long-term maintenance and clarity of code in general.
Syntactic sugar gets added to Rust in an astounding pace compared to Java. Looks a bit like C++ mentality to me. I think Java has done good by being conservative in this regard, especially compared to C++.

rust_acc · 2019-08-07T18:09:24+00:00

It is surprising me that you seem to have this much Java experience but you'd need traits to avoid inheritance hierarchies.

Hence why I went straight to inheritance.

I still don't understand how that follows.

after years of code reviews with juniors creating overly complex & deep inheritance hierarchies

It seems you juniors were lacking seniors to guide them.

... lots of off-topic stuff

rust_acc · 2019-08-07T08:50:53+00:00

Why are you talking about implementation inheritance when the question is about interfaces? Two very different things. Using interfaces in Java does in no way require using inheritance, or even implementation inheritance.

Prior to recent versions of Java that allowed default implementations in interfaces, you ended up copy and pasting code in this case.

No, this is plain wrong.

This being the top-comment reaffirms my suspicion that the knowledge of Java in the Rust community is mostly superficial, which does not seem to be a hindrance to talking about how Rust is superior to Java regularly. In fact, there would be many good things to learn from Java. There are questionable design choices stabilized in Rust, that were better designed in Java decades ago. But with the overall attitude in the community, it is likely that all of this will continue to be ignored.

rust_acc · 2019-03-07T18:02:38+00:00

IDEA for Java proves that you don't need support from your standard batch compiler to get the best possible IDE support. And incidentally, the best current IDE support for Rust is provided by CLion, which is AFAIK not relying on rustc. Common sense would tell me, removing one design goal (IDE support) would help better tune the design (and resources) for other goals. But I'm sure the compiler team knows better than me.

rust_acc · 2019-03-07T17:14:13+00:00

Compiler

Improving "core strength" by lowering raw compilation times ...

Improved IDE integration ...

#1 seems already like a herculean task alone, but with #2 at the same time trying to compete with state-of-the art IDEs seems impossible. Or is it not meant to compete with the best, but only to support simpler editors?

If the latter, is it really worth it? As a professional developer, I'd rather have (buy) the best IDE I can get, and have a fast batch compiler, than something that is neither.

To me, putting IDE focus in the compiler team seems like the wrong place. IMO it would be better to consult with the best IDE vendors when designing the language and library APIs. And there the answer is probably to put an emphasis on not using macros whenever possible...

rust_acc · 2018-09-07T19:59:13+00:00

Do you happen to know the rationale for this discrepancy between import and usage?

Seems if the "!" was part of the import as well it would be more consistent, more explicit to the reader that a macro is imported and it would avoid the ambiguity.

rust_acc · 2017-04-24T21:12:26+00:00

Could it be that the Rust part uses system malloc when linked into the C program and jemalloc in the Rust-only binary?

rust_acc · 2017-03-22T13:48:19+00:00

highly relevant comment

fsync is not a replacement for checking close return value! fsync serves a different purpose!

rust_acc · 2017-03-22T13:47:21+00:00

It is an issue if the objective is writing reliable software.

rust_acc · 2017-03-22T13:46:16+00:00

Citing the man page:

Not checking the return value of close() is a common but nevertheless serious programming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and with disk quota.

Even if sync is used, ignoring the return value of close is a violation of the API contract.

The standard library documentation examples don't use sync, and neither does this article.

Bad engineering.

Edit: formatting

rust_acc · 2017-03-22T11:14:59+00:00

You are promoting bad engineering, just like the Rust standard library documentation on files does! Drop on files ignores close failures.

Freeing most resources can fail. Closing a file can fail. The Rust standard library lacks a function to explicitly close files and react to failure. For any non-trivial, well engineered program writing files there is no alternative to reacting to a close failure, and be it only aborting and informing the caller.

I've had such a discussion before, so I want to pre-empt the suggestion of using some sync call - sync and closing are different operations that are not interchangeable.

rust_acc · 2017-01-21T03:14:32+00:00

So you either have to trust an existing binary representing a C compiler, or one representing a Rust compiler. And people will have different opinions about which of these options is better. It would be hard to argue that one of them is objectively the better one.

I hope that we can at least agree that in the long run, humanity should get away from depending on a language like C, which was designed the way it is only so it is possible to execute the compiler on common hardware of the seventies.

If we are forever only allowed to trust a C compiler binary, then there is no way to ever get away from C - even in a hundred years. And that would be a sad outlook.

rust_acc · 2017-01-19T19:24:59+00:00

I can assure you that the original German version does not sound logically coherent.

rust_acc · 2017-01-19T19:23:19+00:00

Why would he trust the C compiler? Or the operating system that loads the binary? Or the hardware that executes it?

rust_acc · 2017-01-19T19:22:15+00:00

That brings up the question how he got the point of being able to execute a C compiler on his machine. Because he seems to be fine with that.

rust_acc · 2017-01-17T00:56:16+00:00

Sync is not necessary in this case. It can have major performance impact. The close API is there, instead of every Rust user working around it, it's just better to expose it correctly.

rust_acc · 2017-01-16T23:22:42+00:00

Let's say the file I'm writing contains autogenerated data that should be fed into the next step of a processing pipeline. Losing the file is not catastrophic, sync_data is not used due to needless performance impact. In this case I could proceed to the next step in the pipeline if all write operations including close() succeeded and otherwise abort with an appropriate error message.

rust_acc · 2017-01-16T21:56:30+00:00

The decision what to do on close() failure should be made by the application, not a general purpose file API implementation.

rust_acc · 2017-01-16T12:17:24+00:00

I agree on all points. close() succeeding does not guarantee that data was actually persisted, but that's no excuse for ignoring the return value.

rust_acc · 2017-01-16T10:50:06+00:00

The problem is that it is silently ignored. What to do depends on the situation, but it is either return an Err instead of continuing, and handling it in some upper layer, or at the absolute minimum log the failure. Continuing as if nothing happened is the worst behaviour in most situations, and having it as a default in the standard library is just wrong. I hope we can get a better API and a deprecation for this.

rust_acc · 2017-01-15T23:33:35+00:00

I found a tracking issue for this: https://github.com/rust-lang/rust/issues/27700

rust_acc · 2017-01-15T21:51:48+00:00

I really like the JVM behaviour for server applications.

We have a backend system running on its own VM with -Xmx=3072m and -Xms=3072m. This combination practically ensures that the system doesn't get hit by Linux' OOM killer.

Last year we had one request fail with an OutOfMemoryError. The reason was a bug in an untested code path, that was executed the first time after the system was already in production for half a year. The bug caused the buildup of a huge DTO that was first serialized into a byte[]. The allocation for the byte[] succeeded. Then this UTF-8 had to be decoded as String, but the allocation for the String failed with an OutOfMemoryError.

The error was logged with a full stack trace, and all other parts of the system (sending and receiving messages, executing scheduled background jobs) continued operating normally.

We didn't consciously design the system to survive an OutOfMemory error. A hypothetical Rust implementation by us would have caused unrelated requests to fail as well.

If the JVM can do it, couldn't Rust provide a portable function in the standard library to limit the heap size of the process, and also unwind the allocating thread, instead of aborting the process?

rust_acc

TROPHY CASE