I’ve specifically asked about this recently and the answer is that API is not top priority. My guess is that Search API will continue to be in Beta in the next 12 months.
Submodules are the feature you discover someone pulled in when things don't work, and after a bit of digging, you realize it's because the submodule wasn't initialized, and it didn't say so anywhere.
I suspect the opposition to submodules comes from the poor (manual) integration.
As someone suggested in another thread, they ought to auto-recurse by default.
But I don't think that's going to happen, either.
Maybe something like direnv where it tells you about the unloaded submodule once you enter the repository. Except that won't work for IDEs.
The consequence of voting for a 3rd minority candidate is that your vote will effectively be wasted. Or, perhaps in a less pessimistic view, a protest vote, a flavored way of blank voting. In several European voting systems, parties form coalitions, so your vote will only go to waste if the party you vote for fails to cross some minimum boundary, e.g. 2%.
As for buying electric cars, you still have at least 10 models to choose from that won't have a really bad, unfixable experience, or a high risk of the car brand going bankrupt.
So comparing buying Tesla and voting Trump seems a little simple.
So... why should I buy a $35 introductory programming book in 2024?
Here are some free introductory Rust books:
- The Rust Book: https://doc.rust-lang.org/book/
- Rust 101: https://www.ralfj.de/projects/rust-101/main.html
- Rust by Example: https://doc.rust-lang.org/rust-by-example/
- Easy Rust: https://dhghomon.github.io/easy_rust/
- A Gentle Introduction to Rust: https://stevedonovan.github.io/rust-gentle-intro/
Although I typically show people Rustlings, because it teaches programming workflow.
What am I getting for $35 that isn't covered excellently for free already?
Here are some books I spent money on in the last 5 years:
- Functional Design and Architecture, by Alexander Granin
- Production Haskell, by Matt Parsons
- Thinking with Types, by Sandy Maguire
Being a seasoned developer, I would pay money for someone to fast-forward me through advanced concepts.
Here are some examples of free Rust books covering advanced examples:
- The Rustonomicon: https://doc.rust-lang.org/nightly/nomicon/
- Rust Design Patterns: https://rust-unofficial.github.io/patterns/
- Effective Rust: https://www.lurklurk.org/effective-rust/
- Rust Atomics and Locks: https://marabos.nl/atomics/foreword.html
- The Little Book of Rust Macros: https://danielkeep.github.io/tlborm/book/index.html
- Burn: Deep Learning Framework: https://burn.dev/burn-book/
- API Development with Rust: https://rust-api.dev/docs/front-matter/preface/
- Rust Compiler Development Guide: https://rustc-dev-guide.rust-lang.org/getting-started.html
I'd pay money for any of those. Not sure about an introductory book, considering the availability of good, free books.
They are great in each their way, but they're niche.
Production Haskell is for people who want to take their academic Haskell and turn it commercial. There's a lot of practical advice, both coding and non-coding.
Thinking with Types is a very good introduction to type-driven , but the later chapters assume very strong type systems (type-level functions, higher-kinded types, etc.) so you may not be able to apply this kind of modelling outside of Haskell, PureScript, Idris, LEAN, etc.
The book that translates best into any environment is Granin's Functional Architecture.
I can warmly recommend that one even if you're not venturing into FP as a whole.
I can't compare it to a whole lot of other software architecture books, though.
I’ve found Vue easier to learn because it bundles things and lets you learn visual components before fully exploring the reactive model. So while the modularity of React is preferable to a seasoned developer, it does no good to a newcomer.
When I took the compiler course at university, the professor would have a new coursework theme every year, and the year I took the course, the coursework compiler was exception-oriented. So exceptions were the only control flow mechanism besides function calls. If/else, while, return were all variations of throw.
To me this proved that there's nothing inherently wrong about exceptions.
It's how you structure your code and the implied assumptions you share with your colleagues.
Some people are way too optimistic about their program will actually do.
There is some DX similarity between checked exceptions and Result types.
Because the compiler will fail if you don't explicitly mention each possible exception.
But checked exceptions are coming out of style: They're unchecked in C#, and frameworks like Spring Boot in Java catch all checked exceptions and rethrow them as Spring Boot flavored unchecked ones.
For unchecked exceptions and Result types:
The DX is very different in one critical way:
With Results you constantly have to differentiate between error and ok states, before you proceed. With unchecked exceptions you generally assume you're always in an ok state. It's equivalent to wrapping your whole function body in 'try { ... } catch (Exception e)'. And you can get that with Result types in Rust by using '?' and not worry about doing something half-way.
>Because the compiler will fail if you don't explicitly mention each possible exception.
But only the first time. Once you add `throws FooException` to the caller signature, the compiler won't complain about any future callees that also happen to throw FooException, even if you did care about handling their exceptions yourself. With callees that return Result you do get to make that decision for every callee.
I would say "adding Result to the caller signature" provides a similar cascade, but it's not entirely true: Every call must separately be unwrapped. So consistently wrapping your Result calls with the '?' operator is similar to a gigantic try-catch block or adding 'throws CheckedException' everywhere.
So both the '?' operator and adding 'throws CheckedException' everywhere let you accidentally neglect proper error handling: You have a default that is syntactically almost invisible and frees you from thinking. The checked exceptions give you a little more freedom from thinking than the '?' operator.
>So both the '?' operator and adding 'throws CheckedException' everywhere let you accidentally neglect proper error handling: You have a default that is syntactically almost invisible and frees you from thinking.
No. You're choosing to write the `?` there to bubble up the error. It's a compiler error if you forget it. Whereas with `throws FooException` you only get forced to remember it the first time, and after that you're allowed to forget it.
...but you're not choosing to write the `throws FooException`?
I can only say that if the `?` weren't around and you had to write more verbose handling each time, having the question "How should this one particular error be handled?" might come up more often and might prevent more bugs than when you can carelessly `?`-annotate your way through a dozen lines without any equivalents of `finally { ... }` anywhere.
Using separate directories makes improper deletion likely.
Using separate computers with full-disk encryption and shredding procedures makes proper deletion a happy path.
It's not that you cannot properly isolate environments on a single computer.
It's that a single computer is, unless you're a Qubes/BSD/Hypervisor fanatic, not very isolated at all.
So if/when your personal computer gets compromised because of a browser zero-day, your work's intellectual property is potentially compromised.
When you combine that with likely not deleting files properly (or at all), the window of opportunity for IP theft is much bigger.
When you further add the complete unlikeliness that former employees/contractors will report that their personal computers were compromised after having neglected to properly purge your intellectual property, the case for buying your employees/contractors dedicated machinery becomes a no-brainer. Simply from a corporate risk perspective.
It's not a practical problem, but a principal + legal problem.
I fully agree it's a legal problem, which is what my point was from the beginning — depending on the circumstances, it might apply to you or not.
Companies both have to have a set of "processes" in place for legal/compliance reasons, and an employee is liable if they do something that's outside the recommended practice (like using a personal device when forbidden by such policies).
Still, the focus should be on liability and ensuring compliance with legal terms, and an employee needs to make sure they do that. In some cases, that's easier done with a separate computer. In others (when there is no direct spelled-out requirement), downsides of using a separate device outweight the benefits of making compliance with legal terms easier.
As a side note, a browser zero-day is probably even more likely to target work computers, so that example is pretty bad — company data remaining on personal devices by accident is where the problem really is.
reply