681–690 of 736 posts
Earlier quoted context omitted.
There are a few, and they aren't something that I can't live with, of course. A great example of the sorts of things I'm talking about are Rust's insistence on camel case and snake case.
You can turn off certain linting rules in the global cargo config, but yeah I don't see why camel case shouldn't have capitals etc. either.
Earlier quoted context omitted.
You should try diving into num for like a month and see how you like it. It's different enough that you need to go past a certain kind of ledge to start liking it. Or at least that was my experience. For me, it shares the most important benefits of Rust but with quite a lot more ergonomic coding model.
Nim on paper is great; it has many advantages over Rust in the general purpose "niche". Tragically, it's kind of stillborn. It's older than Rust, has orders of magnitude less mindshare, and has no companies with serious technical reputations backing it.
Earlier quoted context omitted.
> Later comes along Go. No dependency management at the start. There ended up being two ways of specifying dependencies. At least one included putting github.io/username/package into your code. That username changes and all your code has to change. Awful design. "github.io/username/package" is using a domain name, just like Java. Changing the username part is like changing the domain name--I don't see how this is any…
Note that in Java it is merely a convention to use domain names as packages. There is no technical requirement to do so. So moving to a different domain has no impact whatsoever on dependency resolution. Many people use non-existent domain names. To be honest I really like how Java advocated for verbose namespaces. Library authors have this awful idea that their library is a special little snowflake that deserves the…
Earlier quoted context omitted.
I used to be .NET dev and don't agree. Couple of reaons: 1) Modern Java is almost as good as C# with some things I can't give up in Java (static imports => succint code, Groovy Spock => succint tests) 2) Kotlin is better than C# 3) JVM has much much bigger ecosystem (almost all the apache projects are JVM oriented) and default web framework is much less code to type (SpringBoot) is much more productiv 4) JVM has wide…
I think Java is only good for long-running servers. Java doesn’t support C interop. For many desktop and embedded projects this is a showstopper, here’s an example https://github.com/Const-me/Vrmac/tree/master/VrmacVideo That C# code directly consumes V4L2 and ASIO Linux kernel APIs, and calls unmanaged user-mode DLLs like libfdk-aac.so and liba52-0.7.4.so. Native stack and value types in C# reduce load on GC, and th…
My point is if you are doing business (especially web) apps. Use one of JVM langs insted of C# because ecosystem is much bigger (and it has fresher langs as well like Kotlin - if that's what you care about)
Earlier quoted context omitted.
> Thus, the compiler theoretically has the liberty to emit whatever it wants for this program. In theory, sure. In practice, what does it do? We can look and see.[0][1][2] (I don't know of any compiler that emits garbage in the example you listed). For some reason, there's this sentiment that's arisen that treats undefined behavior as some sort of bugaboo that's capable of anything and everything (including summoning…
First of all, and most importantly, we're not talking about Undefined Behaviour, which happens at runtime, but about IFNDR (Ill-formed, No diagnostic required), which means at compile time your program has no meaning whatsoever because it's not a well-formed C++ program after all but your compiler doesn't tell you (and because of Rice's Theorem in many cases cannot possibly do so as it can't determine for sure itself…
From the link I posted, from cpp reference, which gives a definition for what constitutes undefined behavior:
>> ill-formed, no diagnostic required - the program has semantic errors which may not be diagnosable in general case… The behavior is undefined if such program is executed
And as for the rest of your argument, you still haven’t answered the one question that matters. Is an executable file with machine code well-defined? If it is, then once you compile a C++ program, the generated binary is well-defined. And once again, all the superfluous arguments about what could happen are irrelevant when there’s no context provided. There’s lots of different types of undefined behavior. An integer overflow by itself does not make your program susceptible to remote code execution. It’s the fact that the integer overflow gets stored in a register that later gets used to write to invalid memory, and then that invalid memory has harmful code injected into it that gets executed.
We should strive to engineer correct software. I agree. It’s all this hand waving about how all undefined behavior is equal that irks me. Because it’s not true, as evidenced by the example listed above about the program that’s “technically” ill-formed C++, but in practice compiles to a harmless program. Engineering requires an understanding of what could go wrong and why. Blindly fretting about all undefined behavior is useless and doesn’t lead to any sort of productive debates.
Engineering is all about understanding tradeoffs. Which is one of the reasons the C++ spec does not define everything in the first place. The fact that in 2023 people don’t understand that all decisions in software come with a tradeoff is lunacy. And once again, I agree that undefined behavior is bad, but to pretend that the existence of IFNDR means the whole language is unusable is silly. People use C++ everyday, and have been for almost 40 years. I’d like more productive conversations on how rust protects the user from the undefined behavior that makes an impact, not about how it doesn’t have IFNDR because that’s irrelevant to the conversation entirely.
Earlier quoted context omitted.
IMHO Rust's ergonomics problems aren't caused by the borrow checker itself, but have the same cause as similar problems in C++ (mainly a "design by committee" approach to language design and implementing features that should be language syntax sugar in the stdlib instead, which then directly results in the stdlib being too entangled with the language and "too noisy" hard to read code). Apart from the static memory sa…
I agree with this. The borrow checker itself isn't the problem. That's necessary to make you write correct and safe code anyway. The problem is that there is too much syntax, too many symbols, and too many keywords. I just keep forgetting how to use impl and lifetimes and single quotes and whatnot. It makes it really tough to use as an occasional language. And if I can't do that, then how can I get confident enough t…
This is exactly how I feel about Rust.
There are some good ideas in there, hiding behind a horrible language design. I am waiting for someone to provide a more developer friendly alternative with the simplicity of C or Go.
Earlier quoted context omitted.
The left pad issue was kind of wild coming from the enterprise Java space. Supply chain attacks against open source software were already being taken pretty seriously, my last company had it's own Maven repository manager running that was used to stage and vet packages before they could be used in production.
> The left pad issue was kind of wild coming from the enterprise Java space. This may be a little off topic for this comment thread but this is a little misrepresentative. Hosted private repos for enterprise weren't exclusive to Java at the time of left pad - anyone doing enterprise node likely had one for npm too & were probably well prepared for the attack. Such enterprise setups are expensive though (or at least t…
Earlier quoted context omitted.
There was a conscious decision to avoid providing a vast standard library because those inevitably become outdated with time. Building a standard library is relatively easy, maintaining for decades is hard. But it’s a trade off because there are concrete upsides to a large standard library. I wrote about this more - Rust has a small standard library (and that’s ok) - https://blog.nindalf.com/posts/rust-stdlib/
That does seem to align with my perception of where Rust wants to be: a low-level systems language. For example, the stdlib provide a time package that deals with duration and instant, sufficient to interact with file systems and such, but leaves dealing with dates, times, and all that complexity to the chrono crate. What I would encourage the Rust community to focus on is adding security-sensitive functionality to t…
I don’t think low level languages mean you need a small standard library and high level means you need a large one. You’re pattern matching between Python, Java, Go (all large, older) and now Rust (small and newer).
Rust wants to be high level as well, allowing people to solve all kinds of problems of varying complexity in different domains. And to some extent, Rust has succeeded in empowering folks to do this. Rust has found its way into “systems” like browsers (Chromium, Firefox) and Operating Systems (Windows, Linux) but also web software, infrastructure (firecracker), developer tools (ruff, turbopack) and other domains.
Like I said, the request for a larger standard library is a reasonable one. But I don’t think it’s going to happen, because Rust seems to be gaining traction in multiple domains without it. By the numbers it looks like it’s growing 10x every 3 years (https://lib.rs/stats). In such an environment, the folks at the wheel would double down on their approach rather than fundamentally rethinking it.
Earlier quoted context omitted.
I agree with this general feeling, and it is hard to articulate Rust forces you to figure out ahead of time where each bit or byte is going to go and on which thread and using which mutation scheme. I’m happy to play the game, but it feels tedious for anything short of a parser or a microcontroller. It messes with my process because I like to get something working before I determine the best API structure for it I ca…
I’ve written plenty of Rust code in my life (easily more than 100kLOC, and I’ve really never worried about putting which bit where. You can just clone and be on your merry way; you don’t need to worry about perf-related things if you don’t want to.
Swift makes every type implicitly copyable on the stack, including object pointers (through ARC), so you don’t have to clone. You can even pass functions as variables without any hoops.
I love lots of things about Rust, though, and will continue to use it for lots of things. Cross-platform things, for one!
Earlier quoted context omitted.
fn trust_me_i_dont_need_a_borrow_checker (x: &'a mut u32) -> &'b mut u32 { unsafe { core::mem::transmute(x) } } fn main() { let mut owned = vec![40, 2]; let mut_1 = trust_me_i_dont_need_a_borrow_checker(&mut owned[0]); let mut_2 = trust_me_i_dont_need_a_borrow_checker(&mut owned[1]); drop(owned); let undefined = *mut_1 + *mut_2; println!("The answer is {undefined}"); }
If unsafe disabled the borrow checker, you wouldn't have needed that transmute. But it doesn't, so you needed the unsafe transmute to make this work.