Fine - for each industry "X", when will a CEO of a company who is given oligopolistic control over software which is deeply entrenched in a stranglehold over "X" decide to fund desperately needed improvements to said software?
Presumably the CEO would believe that improving the quality of their company's products will lead to increased profits/revenue.
I think the main problem is that Rust doesn't allow for basic data structures like graphs or doubly-linked lists without extra effort, which is why I've generally always preferred pseudocode.
I often hear this and am confused; not only are things like 'object soup'[0] possible and straightforward (putting things in collections and referring to them by indices), I never concretely hear why a graph or doubly-linked list becomes uniquely difficult to implement in Rust (and would genuinely be curious to learn why you feel this way). If you needed such data structures anyway, they're either in the standard library or in the many libraries ('crates' in Rust-lingo) available on Rust's package registry[1]---using dependencies in Rust is very straightforward & easy.
- From the perspective of e.g. C++, I don't think it's reinventing the heap. We often prefer to use indexes into a std::vector or similar, even when putting everything in std::shared_ptr is an option, because the dense layout of the vector gives us the blazing fast cache performance we crave. It also avoids memory leaks from reference cycles.
- From the perspective of e.g. Python, yeah it's reinventing the heap. Unless you need to serialize the whole collection into JSON or something, it's much less convenient. But (almost) no one uses Rust instead of Python just for the convenience. (There are dozens of us! Dozens!)
One of the reasons to reach for a low level language is to have control over tradeoffs specific to your use case instead of using some pre-packaged option. Data structures are a very good example. Generic data structures like those in the standard library will likely suffice for many use cases, but a low level language must give the user the control to write their own. It’s just table stakes for this type of language.
Thankfully, rust does give you that level of control, you can write your own doubly-linked list implementation if you want, and you can pick your safety-overhead tradeoff.
Not sure about Rust std. But on cpp I heard a lot low-level companies avoid using its standard library since it is too bloated and optimized for too many cases.
Well, one can always emulate that in Rust with array indexes. And it will be closer how the actual CPU works where a pointer is just an offset into a memory chunk.
Perhaps this is the reason performance oriented articles prefer Rust. In allows to skip a lot of memory allocation while still catching memory-safety bugs, which is a hard problem with C++.
How could something to implement a pointer be more straightforward than a pointer? People seem to like Rust in excessive, sometimes botheringly excessive proportions.
I don't think the indexing strategy is more straightforward in general. It's a thing you have to learn, and the fact that you have to learn it is part of Rust's famously steep learning curve. That said, there are some common cases where you might wish you'd used indexes instead of pointers in other languages too:
- Working with resizeable collections like std::vector in any non-GC language, where resizing invalidates pointers.
- Serialization. If your objects contain indexes to each other, it's easy to turn them into e.g. JSON. But if they contain pointers to each other, it's tricky.
Not easily. But not all use cases require it. The regex crate makes heavy use of this pattern for finite machine states, for example. But this fits nicely with an arena allocation pattern, so everything can just be dropped at once.
I'm not sure whether this is exactly what you mean, but when you need to support deletions you can switch to a "generational" collection like Slab or SlotMap. Your indexes are still integers, but under the covers some of the bits get repurposed to disambiguate new elements that reuse old slots.
Those are fairly straightforward to implement if you are ok using a reference counted type (along with weak references), although that will hurt performance. That would be similar to using a shared_pointer in c++.
And you can implement code similar to what you would in c or c++ if you use raw pointers and unsafe code.
Where you run into difficulties is if you want something that is fast and safe. And then you need a more complicated design that probably involves using indices into a Vec instead of pointers.
Using a Vec actually has some benefits beyond the safety guarantees from rust. There are fewer allocations, and you probably are more likely to get nearby nodes on the same cache line.
It's best for me when I do something that I ordinarily don't do for AoC.
I find no particular pleasure in using an everyday language like Python for it, because as you said it's too easy.
I have used Haskell, Racket, and in some easier cases APL and it's been fun. Treating it more like a puzzle than an actual programming assignment.
When learning new languages, it's best to do something that actually makes you think in a different shape. If you know Python, don't do Ruby. If you know Java, don't do C#.
It goes into "too bothersome" territory in this case for me. Competing in a local leaderboard was fun and kept me engaged until the end, but it was only possible by choosing a comfortable language to be free to actually think about the puzzle itself to solve it fast. Choosing something that I'm not already familiar with (or that isn't well-suited for this type of tasks) is a great way to ramp up the difficulty and perhaps gain some bragging rights, but I can't see me doing it for longer than a few days before losing interest. Even in this "easy mode" in Python, there were four days that had me spend more than an hour (up to 5h) on the task. There's plenty of actually useful projects I could do in this time to learn new things instead after all.
> There's plenty of actually useful projects I could do in this time to learn new things instead after all.
I suppose. I do actually useful projects at work. AoC reminds me of why I personally loved programming in the first place - solving small technical puzzles. I don't like trying to make every single moment of my life "productive".
When I said "useful", I meant "useful to me". I figure I'd prefer to solve some problem to scratch a personal itch, or play some instrument, or make a funny game, whatever. Even spending that time on resting would probably be useful. Solving a technical puzzle is nice, but my point was that collecting stars to finish the advent calendar isn't particularly useful or rewarding on its own, and if I need to be motivated internally to do it by adding some artificial challenges, then I can find more enjoyable ways to make myself busy as well.
But that's just me. I just don't think AoC could motivate me into learning something I wouldn't learn otherwise. It just doesn't provide enough incentive to keep going. Tasks are mostly too easy to be rewarding on their own, but some are too hard to just do casually. I can't imagine spending as much time as I did on it - about 30 hours in total, not counting time spent on golfing and browsing other people's solutions etc. - if I had a regular job at the time, and once you skip days it just becomes a random set of challenges that could be tackled at any time anyway.
It doesn't do: partial application, currying, structurally constrained generics and gradual typing (and of course much more small details that e.g. F# can do)
It does do: higher order functions and functional composition, monads and monadic comprehensions, records, list comprehensions and iterators.
You are correct that it's not going to "push" you into that direction aside from APIs that are already popular, but it's unfortunate it keeps getting bundled together with Java. C# and Java are languages with differing priorities, paradigm support and target scenarios. There is great overlap, but the differences are significant.
I assume this is satire, but for those who might take this seriously, please avoid doing tricks like this.
You're doing so much extra work here. Creating many new arrays, running a bunch of extra function calls, creating extra closures, and really obfuscating code from the engine. This will tank performance.
This is the point at which people come back at me with something about "premature optimization" being bad. That's all well and good, but if you prematurely pessimize and let these patterns creep throughout your codebase, you end up with products that are significantly slower than they should be.
I've spent quite a while working on JS engines, and it always impresses me how much extra work exists in JS developers' code, seemingly for no real reason, and it's slowing down the entire internet. This doesn't appear to be better for the developer, the user, or any potential future maintainers.
> IMO, the Kindle is the premium e-reader when it comes to look and feel. It's just a fantastic experience.
Interestingly, I switched from Kindle to Kobo because it was lacking various basic features that made it not feel premium.
* Kobo epubs can show "pages in chapter" progress so I know how much longer there is until a nice stopping point, while Kindle only shows "minutes left in chapter" which is functionally useless.
* Kobo had blue light blocking night shift before Kindle Paperwhite (I think both have it now?)
* Kobo had a convenient feature where you slide your finger along the side of the screen to change brightness, instead of having to go into multiple menus to do this.
It's possible these things have been remedied, but especially the chapter progress thing put such a bad taste in my mouth that I never wanted to touch Kindle again.
> Kindle only shows "minutes left in chapter" which is functionally useless
The kindle recomputes your reading pace as you go, so unless you prefer to do that math in your head and track your own pages-per-minute moving average, I don't see how it's functionally useless
I always find Kindle's "minutes left" too low for some reason, so I have to ignore it. I'd find it simpler - and easier to make progress - if it just showed pages read/remaining within the chapter. Absent that, I am often having to go through the distraction of using the overview feature to figure out where I am in the chapter.
I should probably post on MobileRead with this question instead, but I wondered if you might have insight into this issue I've been having with my Kobo.
I've noticed that when I read on my Kobo I run into issue with ebook files. When I use Calibre to send .epub files I'll have lots of reliability issues; books will freeze up, pages won't turn, whole sections of the book wind up being unreadable, stuff like that. Having Calibre reformat books in the kobo epub format seems to help some, but I still have page turn issues from time to time.
Have you see any of this behavior before? As far as I'm concerned this would be the perfect ereader if it were just more reliable.
> Advent of Code, are so heavily focused on making clever use of math, data structures and algorithms
I've done a fair amount of Advent of Code and I wouldn't say it's at all "focused" on this. The vast majority of the questions use hash tables and graph traversal as the full extent of their use of math/DS/algos.
There's always one or two puzzles every year that require some particular math/CS insight but most of them just need you to know BFS and/or how to write a parser.
Your examples are also not bad, but they seem to be primarily concerned with "getting familiar with a new programming language" in the context of writing a web server, which is one of the parts of programming I try to stay away from. Most of your examples require less familiarity with the language's features and more with libraries you might use, which is less interesting to me personally (then again, I'm a PL fan and I write compilers for a living).
Meanwhile, I like AoC because I've used language features to take the fairly straightforward potential implementations and write them more elegantly in the language I choose. e.g. I use Monads in Haskell, or use Rust's easy threading to parallelize solutions, etc.
For me, learning a new programming language is largely uninteresting unless it changes the fundamental "shape" I think in, rather than what the exact names of the libraries I use change to. e.g. I already know Java so I'm not really going to bother "learning" C#. I already know Python so I don't really bother diving deep into Ruby, etc. However, I learn Haskell, Rust, Forth, Erlang, Scheme, etc.
AoC is still is algorithms and data structures: there's minimal interaction with the outside world, just solving the problem for the input data. It's just about coming up with the algorithm yourself instead of applying fancy well-known ones.
I think a lot of people here would be surprised how much of a step up this is from classic leetcode or DSA stuff. I have been involved in introducing people to AoC and helping them and the amount of people who have basic knowledge of algorithms but struggled to parse the input from a file was a little shocking to me at first. Of course, I do not blame anyone for not knowing something, classic academic courses can be misguided sometimes.
This doesn't negate the fact that there is somewhat of a lack in problems with more outside world interaction and it would be cool to see more of that.
Exercism.io does what you want? It has language tracks and each track has questions geared to seal your understanding of some language concept. It also has it gamified by building a community around it and folks comparing their solutions.
> You still have the precise output if you want it, it didn’t go away.
For now. Given that most new devices seem to be fully hostile to the concept of general purpose computing (see phones, VR devices, TVs, etc), I wonder how long it will be before many of the computers that are sold are even more locked down than Chromebooks - just a few prompts for interacting with a preinstalled LLM.
VP - Tells directors to work faster
Director - Tells managers to work faster
Manager - unblocks team
ICs - do real work