31–40 of 127 posts
Earlier quoted context omitted.
Neat, what is your use-case for OBD-II data? I've been investigating ways to get data from a race car back to the pit crew via something like a raspberry pi.
The microcontroller component of that is going to be a walk in the park compared to the radio component.
> Rust is much easier to teach than C or C++, Not sure about that. If you know C, which is easy to learn, you already know a lot about C++, or at least the parts that are used most of the time. Learning about the borrow checker, match enums don't seem very easy at first, although they surely seem elegant and much safer.
Most C++ people I talk to would strongly disagree that in C++, you should do things the C way.
Earlier quoted context omitted.
> 1. What development environment are other developers using with very large code bases? Is the tooling responsive? It’s solid. If you’re coming from Visual Studio, you’ll dig IntelliJ with the Rust plug-in. > 2. Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators for async (assuming you want to stay on stable)? And is there a date yet whe…
> If you’re expecting the F# (and .NET) ecosystem, you’ll likely be satisfied. In fact, it might be better. Not even close (100k unique packages on nuget, 13k crates on crates.io). On the other hand, you have easy interop with C (which doesn't give you stuff like safety, idiomatic error handling or nice APIs, but it's occasionally better than coding it yourself).
NPM claims to have close to 500k packages. Should we assume it solves 5x the problems that the .NET ecosystem does, that that perhaps by the 50th implementation of leftpad, there's some cruft on there?
That's not to say that Rust's package ecosystem is large enough or sufficient in comparison to .NET, just that raw package count gets to be an extremely poor indicator of quality after a certain level has been reached.
As a point of reference, I approach this from Perl and CPAN, which is one of the oldest large fully featured package networks. At this point, the problem is usually not finding a package that provides a solution, but finding the right package out of what's available. Different solutions exist, but a good curated list of well implemented solutions to common needs can help quite a bit.[1]
> while the Java server could use up to 5GB of RAM, the comparable Rust server only used 50MB How...how is that possible? It just glosses over this interesting point. What does "comparable" Java code do to use 100x more memory?
Three things: * Java tends to allocate things separately and manipulate pointers, while Rust allocates things inline. This introduces allocation overhead and eats up the space needed by the pointers themselves. * Java uses a JIT, which consumes of memory for profiling state and for storing the resulting compiled code. * A tracing garbage collector needs about five times as much memory as explicit freeing to reach the…
Just a small nit but the term you're looking for here is "value types". Rust does heap allocations(with the pointer overhead) via Box, you just get explicit control over the overhead and cost.
> Rust is much easier to teach than C or C++, Not sure about that. If you know C, which is easy to learn, you already know a lot about C++, or at least the parts that are used most of the time. Learning about the borrow checker, match enums don't seem very easy at first, although they surely seem elegant and much safer.
C seems easy at first glance, but has so much manual work(managing memory, dependencies) that working with it is to me - well - tedious.
> Rust is much easier to teach than C or C++, Not sure about that. If you know C, which is easy to learn, you already know a lot about C++, or at least the parts that are used most of the time. Learning about the borrow checker, match enums don't seem very easy at first, although they surely seem elegant and much safer.
Earlier quoted context omitted.
> Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators for async (assuming you want to stay on stable)? And is there a date yet when async/await will be stabilized? Can someone explain to me what async/await is, in the context of a language like Go? I've used Rust a fair amount, but Go has been my native language for ~5 years now. With that…
Yeah, you are missing some details. But this is a huge area, and it's hard to explain in a single HN comment. Basically, yes, the convenience of not needing to write async/await is useful, but in order to accomplish that, you need a bunch of other supporting decisions. These decisions make sense for Go, but do not make sense for Rust. The first thing to say on this topic is that virtually all of this (including async…
This can even be extended to "awaiting across function calls" with effect polymorphism. I haven't seen this done in this context, but it would allow things like passing an async closure, or a generic type with an async trait implementation, to a normal function and having it automatically become an async function instead.
The real choice between explicit and implicit suspension points is thus syntactic, not implementation-driven. The reasoning there is more along the lines of "I like to see where my function might suspend" vs "I don't want to pepper my code with `await`."
> Rust is much easier to teach than C or C++, Not sure about that. If you know C, which is easy to learn, you already know a lot about C++, or at least the parts that are used most of the time. Learning about the borrow checker, match enums don't seem very easy at first, although they surely seem elegant and much safer.
Not sure I'd agree. If you know C you know a very small subset of C++(and growing smaller with each revision). Things like move semantics, exceptions + constructors, lambdas and templates are huge and each one can easily be as complex as straight C99.
Earlier quoted context omitted.
Yeah, you are missing some details. But this is a huge area, and it's hard to explain in a single HN comment. Basically, yes, the convenience of not needing to write async/await is useful, but in order to accomplish that, you need a bunch of other supporting decisions. These decisions make sense for Go, but do not make sense for Rust. The first thing to say on this topic is that virtually all of this (including async…
Technically you can get the convenience of not needing to write async/await, with the same runtime implementation decisions underneath as Tokio/futures. Kotlin is an example of this approach- its coroutines are state machines but with implicit awaits. This can even be extended to "awaiting across function calls" with effect polymorphism. I haven't seen this done in this context, but it would allow things like passing…
Earlier quoted context omitted.
The microcontroller component of that is going to be a walk in the park compared to the radio component.
Wifi with good antennas, or a cellular hotspot seems pretty easy.
Vehicles are not friendly environments to begin with, race cars are outright hostile territory. Vibration & G forces, interference, fluctuating power, huge temperature variation, aerodynamic effects on antenna and cabling are all factors that will make this quite a bit of work to get to acceptable reliability levels.
I like your idea of a cellular hotspot, that might be the easiest way to get to something that works. Compact, no external cabling. That's good.
Edit: I tried running a webcam in a racecar in the mid 90's but it never got beyond the planning stage before the obstacles became insurmountable for the budget available, now, obviously a lot has happened in those years and F1 and other racing sports prove on a daily basis that the bandwidth is definitely there if you have the budget, you make me wonder how easy it would be to pull this off today, mostly likely you could just plug it together from some consumer components, a small tablet with a SIM card in a waterproof and vibration isolated enclosure would probably get you 90% there.