sgeisenh

This closely resembles implicit conversion from C++ and in many serious codebases it is considered poor practice because it leads to a lot of hidden control flow.

I think Rust strikes a nice balance but there’s enough magic that some people still get frustrated. Following traits can get tedious at times.

Yes, for most real-world examples JavaScript is significantly slower; JIT isn’t free and can be very sensitive to small code changes, you also have to consider the garbage collector.

Speed is also not the only metric, Rust and C enable much better control over memory usage. In general, it is easier to write a memory-efficient program in Rust or C than it is in JS.

Similar to ruff, uv mostly gathers ideas from other tools (with strong opinions and a handful of thoughtful additions and adjustments) and implements them in Rust for speed improvements.

Interestingly, the speed is the main differentiator from existing package and project management tools. Even if you are using it as a drop-in replacement for pip, it is just so much faster.

This is an oversimplification. When distributed, the nondeterministic order of additions during reductions can produce nondeterministic results due to floating point error.

It’s nitpicking for sure, but it causes real challenges for reproducibility, especially during model training.

Lifetime annotations can be burdensome when trying to avoid extraneous copies and they feel contagious (when you add a lifetime annotation to a frequently used type, it bubbles out to anything that uses that type unless you're willing to use unsafe to extend lifetimes). The solutions to this problem (tracking indices instead of references) lose a lot of benefits that the borrow checker provides.

The aliasing rules in Rust are also pretty strict. There are plenty of single-threaded programs where I want to be able to occasionally read a piece of information through an immutable reference, but that information can be modified by a different piece of code. This usually indicates a design issue in your program but sometimes you just want to throw together some code to solve an immediate problem. The extra friction from the borrow checker makes it less attractive to use Rust for these kinds of programs.

> Don't waste time on discussions within a level.

I disagree with this. YAML has too many footguns (boolean conversions being the first among them) not to mention it is a superset of JSON. Plain old JSON or TOML are much simpler.

Thanks for the quick response, and for the nice write up. I thoroughly enjoy the python-like pseudocode, it was the main reason I was able to pick that out reasonably quickly!

In the pseudocode snippet that introduces a WAL, the semaphores are signaled before the fsync occurs. This seems like a mistake but maybe there’s a good reason to do this that I am missing?

Edit: it looks like this is the case in the first batched fsync example, as well.

I did some of the work in the post (though mostly post-setup).

Speaking in generalities: the initial failure rates of these units are much higher than those of traditional non-GPU machines.

In general, the failure rates decline significantly during the operating life of hardware. So you deal with a bunch of issues up front that you try to resolve to reach a much more stable state.

There was a recent Meta engineering blog post that echoed some of our own experiences wrangling GPUs and high performance networks: https://engineering.fb.com/2024/06/12/data-infrastructure/tr...

You may want to add some moderation features or otherwise increase friction for adding job postings for www.firmwarejobs.com because the very first listing that I see when I load the page is "Doing your mom".

I think it's more subtle than that. Rust has a notion of non-lexical lifetimes (https://rust-lang.github.io/rfcs/2094-nll.html) and the compiler often completely avoids the use of the stack for small, trivially droppable values, regardless of their lexical scope. In some ways, `let` in Rust is a more C-like variant of the `let ... in ... end` construct from OCaml.

Not to mention that you can always introduce a new lexical scope with `{ ... }` in Rust code.

Stuff Made Here

Usually from GC. Anthony Sottile has a nice explanatory video: https://youtu.be/sdmcCQ7Em04?si=9PObAJixALFiZ9vd

Client means browser in this context.

Unfortunately the generational GC modifies bits all over the heap, so you have to use some tricks to really leverage copy on write (as the commenter alludes to).

I don't think I fully understand the analogy.

Typescript has almost identical semantics to Javascript but adds typing syntax to improve developer experience and make it easier to manage a large-scale JS codebase.

Zig is a fundamentally different language than C that has a lot of new features. Two great examples are comptime and allocators which have complements in C, but are really very different from what C provides.

If you're suggesting that zig is aiming to provide a C alternative with better ergonomics, then I agree; but zig and C have a lot more differences than Typescript and Javascript.

There is an option to circumvent the prerequisites as a non-major:

  You may also get permission from an advisor if you performed very high on the CS Assessment on Canvas.

I took the course over the summer as a music major and subsequently took several other CS courses as a music major after having a discussion with an advisor in the CS department. I ended up finishing a CS degree a year after my music degree. CMU was really great about providing opportunities for students to explore courses outside of their majors, especially over the summer.

"Principles of Imperative Programming" is a misnomer.

The course is really about developing techniques for reasoning about low-level software. You build up abstractions in C by leveraging contracts and writing proofs of correctness based on those contracts.

Explore the "Learning Objectives" section to read about what the course really entails: https://www.cs.cmu.edu/~15122/about.shtml#LO

This was the first computer science course that I took at CMU and it was absolutely mind blowing for me. I had previously taken AP CS and had played around with making games in flash and writing little programs for my graphing calculator. But this course taught me how to reason about my programs (and why that might be valuable, to begin with).

Especially if modular implicits land, you get the best of both functions and typeclasses.

Pretty weird way to start the post.

Doesn't the normal approach in C++ run into similar issues? The workarounds in C++ are more ergonomic than in Rust, but can still require a lot of refactoring.

One of the performance bottlenecks that I ran into while reimplementing clox in C++ was using `new` and `delete` instead of `realloc` for arrays and hash tables. By the time that I figured out it was an issue, I was already using `operator new` to track heap allocations for the garbage collector.

Rust is an interesting mix. OCaml gets pretty close and type inference offers better ergonomics. The fearless concurrency story is still much better in Rust than OCaml.

I'm not sure that it's that cut and dry. Rust provides good tools for building high level abstractions and the developer tooling is comparable to something like typescript. Depending on the team, rust can be a perfectly reasonable choice for a CRUD application.

I have a lot of experience writing microservices and batch jobs using C++. At first this seems outrageous, but with a reasonable set of high level utility libraries, C++ can be very expressive. And then you have the option to drop down to whichever level of abstraction is necessary to address performance or concurrency issues.

Beyond platform requirements (e.g. HTML, CSS and JS on the web or python for ML) I think language choice has more to do with business needs than high level problem domain. When you're building an MVP or have an urgent business need where you need to prioritize short term progress over long term flexibility, high level languages with GC are great. If you have an experienced team and you want to build something that will offer flexibility in the long term, Rust is a fine choice.

Fatigue is a common side effect of Zyrtec (and other antihistamines). From purely anecdotal evidence, I think most people have to experiment with allergy medication to find one that works best for them. I know that I'm dysfunctional when taking Zyrtec but Claritin doesn't bother me at all.

I'm a big fan of Julia Evans' zines. They're short and to-the-point and are often excellent jumping off points.

This one seems highly relevant: https://wizardzines.com/zines/containers/

This was also posted on HN a couple weeks ago: https://earthly.dev/blog/chroot/

Google places a pretty high emphasis on code quality and readability. It's not universally great, but it's a big part of the culture. You can catch a glimpse in their [style guides][1], [abseil totws][2] and [aips][3]. Almost every change is required to be reviewed for "readability" in addition to functionality. This can feel like a lot, but it leads to pretty consistent style across the codebase which makes it a lot easier to switch projects or read and understand an unfamiliar section of the code.

[1]: https://google.github.io/styleguide/ [2]: https://abseil.io/tips/ [3]: https://google.aip.dev/

For folks using bazel, there is also [bazel-watcher][1]. Also worth checking out [watchman][2] for this style of workflow in general.

[1]: https://github.com/bazelbuild/bazel-watcher [2]: https://facebook.github.io/watchman/

This is great advice.

Anecdotally, I've been having pretty bad anxiety this year from work that I feel should be easy but turns out to have many unexpected wrinkles. In retrospect, it seems like there may have been a lot of "justs" when discussing early solutions.

I've started to take a step back when approaching problems to better understand potential obstacles, but this was still a pretty big toll on my confidence.

This looks like a great speaker lineup. Any details on how to attend? Is it all just livestreamed on YouTube?

Depending on how you write it, iterators are much better at this since most iterator methods produce iterators with size hints.

If you use "take" for example, collect should do the right thing: https://doc.rust-lang.org/src/core/iter/adapters/take.rs.htm...

Collaboration on a C++ codebase can be interesting. One of the most common approaches that organizations use is to choose a subset of the language and discourage committing code that doesn't conform to that subset.

This limits the sharp edges and in particular makes it easier to identify where they might exist. Perhaps the most common rule is the prohibition of exceptional control flow. This can seem really limiting at first, but encoding the possibility of errors using the type system and forcing callers to handle errors explicitly is really powerful.