# marcosfede/algorithms: the same problem solved in ten languages

> This repository holds solved algorithmic problems and data structure exercises, mostly in Python, with many of them ported to Rust, Go, JavaScript, Haskell, Julia, Elixir, Scala, Ruby and C++. It is organised by problem category rather than by language, and the checkboxes in the README show exactly which exercises are unsolved.

**marcosfede/algorithms** — Solved algorithms and data structures problems in many languages

- Repository: https://github.com/marcosfede/algorithms
- Stars: 1,130 · Forks: 139
- Language: Python
- License: GPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/marcosfede-algorithms

## One problem, many languages, same directory

This repository collects solved algorithms and data structures problems in many languages, and the organising idea is simple: the same problem appears in several languages side by side.

The README explains the motivation. It is inspired by keon's repository of solved problems in Python 3, and the author wanted to compare solutions across different languages and learn them in the process. The honesty about the contents follows immediately: solutions may be the author's own, or taken from the internet.

That last sentence is the most important line in the project for anyone planning to use it, and it should be read as a warning rather than a footnote. A solution copied from a blog post is not necessarily a correct one, and a solution written by a learner is not necessarily a good one. Nothing here carries a test suite guarantee or a review.

The language list is longer than the repository's own topic tags suggest. The README shows ten icons linking to GitHub code search filtered by language: Rust, Go, Python, JavaScript, Haskell, Julia, Elixir, Scala, Ruby and C++. The search links are the navigation, so the way to browse is to click a language and get a filtered result set rather than to read a curated index.

The primary language is listed as Python, which matches the fact that the majority of the exercise code and the checklist live in Python files, while Rust has a Cargo project layered on top of the same tree.

## The directory layout is the taxonomy

The top level of the repository is a list of problem categories, and it reads like a curriculum.

There are array/, backtrack/, bfs/, bit/, calculator/, design/, dfs/, dp/, graph/, heap/, linkedlist/, map/, maths/, matrix/, queues/, search/, set/, sort/, stack/, strings/, tree/ and union-find/ for the classic algorithm families, plus study_material/ and assets/, and the two event-based collections adventofcode/ and googlecodejam/.

So a problem lives at a path that names both its family and its specific exercise. The README checklist shows the shape: under array/ there are entries for circular_counter, flatten, garage, golf_bot, longest_non_repeat, merge_intervals, missing_ranges, plus_one, rotate_array, summary_ranges, three_sum and two_sum, each with a link to its own directory. Under backtrack/ there is anagram, array_sum_combinations, combination_sum, expression_add_operators and factor_combinations, followed by a run of unticked ones: generate_abbreviations, generate_parenthesis, letter_combination, palindrome_partitioning, pattern_match, permute, permute_unique, subsets and subsets_unique.

The ticked and unticked boxes are the most informative part of the README, and they are honest at the level of individual problems rather than categories. The bit/ category is entirely unticked, with all nine of its entries open, and bfs/ has one solved problem and two open ones. That tells you where the coverage is real and where it is aspirational.

The event collections are indexed by year. googlecodejam/ has 2017 with three problems, 2018 with eleven, and 2019 with four. adventofcode/ has 2018 with days 1 through 23 solved and days 24 and 25 open, and 2019 with d1 through d8 solved.

## Rust sits on top of the Python tree

The Cargo.toml at the root is an unusual thing to find in a repository of exercise solutions, and it explains the Rust angle better than any prose would.

It is a single package named algorithms, version 1.0.0, on edition 2018, with one dependency, itertools at 0.8.2. The interesting part is the list of binary targets, each of which points into the ordinary exercise directory structure:

```toml
[[bin]]
name = "circular_counter"
path = "array/circular_counter/circular_counter.rs"

[[bin]]
name = "bubble_sort"
path = "sort/bubble_sort/bubble_sort.rs"

[[bin]]
name = "merge_sort"
path = "sort/merge_sort/merge_sort.rs"
```

And then the Advent of Code days as their own binaries, named aoc-2019-d1, aoc-2019-d2, aoc-2019-d4, aoc-2019-d8 and aoc-2019-d24, each pointing at the matching day directory under adventofcode/2019/.

So the Rust solutions are not in a separate Rust tree. They sit in the same array/ and sort/ directories as the Python ones, and Cargo is configured to build selected ones as executables. Running one is a cargo run with the binary name, which is a much better experience than assembling rustc invocations by hand, and the fact that the Advent of Code entries get individual binary names means each day can be run on its own.

The dependency list is short enough to be notable too. A single itertools crate for the whole project, at a version pinned to 0.8.2, tells you the Rust solutions lean on the standard library plus that one helper rather than on a framework. The exercises are the point, and the tooling stays out of the way.

## Competition problems are indexed by year and problem name

The event-based directories show a different organisation principle, and it is worth reading the checklist closely because it exposes a mapping mistake.

Under googlecodejam/2017/ the solved problems are Oversized Pancake Flipper, Tidy Numbers and Fashion Show. Under 2018/ there are eleven, including Bathroom Stalls, Number Guessing, Senate Evacuation, Cruise Control, Cube UFO, Go Gopher, Saving The Universe Again, Trouble Sort, Waffle Choppers, Lollipop Shop, and Rounding Error.

That last entry is where the detail is. The 2018 list shows Rounding Error, and the link for it points to the directory googlecodejam/2018/Cryptopangrams. Meanwhile the 2019 list contains Cryptopangrams with the link pointing to googlecodejam/2019/Rounding%20Error. The two problem names are swapped between the two years in the checklist, so the display name and the directory name for those two entries do not line up.

That is the kind of small inconsistency that only shows up if you read the whole list, and it is a useful signal about the state of the index. The checklists are maintained by hand and hand-maintained indexes drift. The links still resolve, and the problems are still there, but if you navigate by problem name rather than by directory you will end up in the wrong year for these two.

The Advent of Code checklist uses a different convention, day numbers rather than problem names, with days 1 to 23 marked done for 2018 and days 1 to 8 for 2019. For 2019 the day directories are named d1 through d8, and the Cargo binaries for the 2019 days follow the same naming.

## What this collection is good for, and what it is not

The strength of the repository is the side-by-side comparison, and there is no way to get that from a single-language collection.

The Python solutions are the reference, since Python is the primary language and the checklist is written against the Python files. The Rust, Go, JavaScript, Haskell, Julia, Elixir, Scala, Ruby and C++ versions are the interesting part, because reading the same exercise in a functional language like Haskell or Elixir next to an object-oriented one is a genuinely different learning experience from reading two Python solutions.

The repository's topic list names interview and interview-practice alongside competitive-programming, and the array/ problems in particular, two_sum, three_sum, merge_intervals, plus_one, missing_ranges, are the classic interview set rather than competition problems. The googlecodejam/ and adventofcode/ directories are the competition side, and the topical categories like dp/, graph/ and union-find/ are the algorithm-course side.

What it is not is a library. There is no package to install, no published API, no semantic versioning, and no test harness that runs across all of it. The Cargo project builds selected Rust binaries, but that is a convenience for the Rust half and does not turn the repository into a maintained artifact.

There is also a quality caveat that the author states plainly. Solutions may be the author's own or taken from the internet, so for interview preparation this is a source of exercises and of alternative formulations. For anything where correctness matters, treat every solution as unverified until you have checked it, and treat the ticked and unticked boxes as a statement about coverage rather than about correctness.

## Repository conventions and the current state

The supporting files at the top level tell you how the project is run.

There is a CODE_OF_CONDUCT.md, a CONTRIBUTING.md, an .editorconfig and a .ci/ directory for continuous integration, plus a .github/ directory. The licence file is named LICENCE rather than LICENSE, and the licence is GPL-3.0, which is worth noting because a collection of exercise solutions is exactly the kind of project where the licence choice matters: copyleft on a pile of community-contributed solutions is a defensible choice, but it is a decision rather than a default, and a commercial codebase that copies a solution out of here inherits the terms.

The .ci/ directory is a directory-based approach to continuous integration rather than the more common workflow-file layout, and the .github/ directory sits alongside it.

On the state of the project, the repository is not archived and the last push was on 2026-10-07, so it is being worked on. There are no GitHub releases, which is appropriate for a collection of exercises with no versioned release process. The topic list includes hacktoberfest, which is a further sign of the contribution model: the project is used as a destination for October contributions, which means the volume of incoming code is likely to exceed the volume of review.

There is also a Gitter chat badge in the README, at gitter.im/marcosfede/algorithms, for discussion of the repository.

The assets/ directory holds the language icons used by the README's search links, and study_material/ holds the reference material the author gathered while learning, which is a different category of content from the solutions themselves and is useful for anyone who wants the theory rather than the code.

## Conclusion

marcosfede/algorithms is a good fit for a developer who wants to see one problem solved the way two or three languages would each approach it, because the same exercise appears in Python, Rust, Go and the rest, and the directory layout makes the comparison trivial; it is the wrong fit as a reference library, since the code is exercise solutions rather than a maintained package with an API, and before you rely on any of it you should read the individual solutions, because the README states that solutions may be the author's own or taken from the internet.

## FAQ

### What is in the marcosfede/algorithms repository?

Solved algorithms and data structure problems organised by category, with array, backtrack, bfs, bit, dfs, dp, graph, heap, linkedlist, map, maths, matrix, queues, search, set, sort, stack, strings, tree and union-find directories, plus adventofcode/ and googlecodejam/ collections indexed by year.

### Which languages are covered in marcosfede/algorithms?

Ten, according to the README's icon links: Rust, Go, Python, JavaScript, Haskell, Julia, Elixir, Scala, Ruby and C++. The links point at GitHub code search filtered by language, so browsing by language is the intended way to navigate.

### How do I run the Rust solutions in this repository?

The root Cargo.toml declares binary targets that point into the ordinary exercise directories, such as circular_counter at array/circular_counter/circular_counter.rs and the Advent of Code days as aoc-2019-d1 and similar, so you build and run them through cargo with the binary name. The package is named algorithms, on edition 2018, with a single dependency, itertools 0.8.2.

### Are the solutions in this repository verified correct?

The README states that solutions may be the author's own or taken from the internet. The ticked and unticked boxes in the checklist show which exercises are solved, not whether each solution has been tested or reviewed, so treat any individual solution as unverified until you check it yourself.

### What licence is marcosfede/algorithms released under?

GPL-3.0, with the licence text in the LICENCE file at the repository root. The repository is not archived, the last push was on 2026-10-07, and there are no GitHub releases.

## Sources

- [Issues](https://github.com/marcosfede/algorithms/issues)
- [License: GPL-3.0](https://github.com/marcosfede/algorithms/blob/master/LICENSE)
- [marcosfede/algorithms on GitHub](https://github.com/marcosfede/algorithms)
- [README](https://github.com/marcosfede/algorithms/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/marcosfede-algorithms