Reaktor Blog
reaktor.com · Company blog · on HN since 2015
Reaktor, a Finnish software consultancy, publishes engineering posts on JavaScript, types, functional programming, and Amiga assembly.
What HN saysHN commenters mostly link it in job postings and praise its Finnish-style benefits, such as four weeks of vacation and limited overtime.
65HN people shared it
20linked it in comments
68stories submitted
2.5Kstory points
3 months agolast shared
2015people per year2026
Most-shared posts
- 1Three JavaScript performance fundamentals that make Bluebird fast6 people · 200 points · first shared 2016 · 63 comments on HN
- 2Homepage6 people · first shared 2015
- 3Crash course to Amiga assembly programming5 people · 203 points · first shared 2015 · 52 comments on HN
- 4Fear, trust and JavaScript: When types and functional programming fail4 people · 263 points · first shared 2018 · 203 comments on HN
- 5How core.async and CSP help you prove your async code works4 people · 150 points · first shared 2016 · 17 comments on HN
- 6Refactoring 30000 lines of JavaScript with types3 people · 16 points · first shared 2017 · discussion on HN
- 7Life after Heroku: What's a dev to do?2 people · 144 points · first shared 2022 · 103 comments on HN
- 8I’ve tracked every piece of clothing I’ve worn for three years2 people · 75 points · first shared 2021 · 100 comments on HN
- 9Why CSP matters II: How do I know sync works?2 people · 43 points · first shared 2016 · 1 comments on HN
- 10Kerbal Space Program-Inspired Rocket Puzzle Written in JavaScript and WebGL2 people · 16 points · first shared 2017 · 3 comments on HN
- 11From radio waves to packets with software defined radio2 people · 12 points · first shared 2016 · discussion on HN
- 12Algorithmic fatigue2 people · 11 points · first shared 2021 · 4 comments on HN
- 13You can write your own React2 people · 9 points · first shared 2021 · discussion on HN
- 14Senior software engineer2 people · first shared 2017
- 15How to grow into your best developer self1 people · 217 points · first shared 2016 · 69 comments on HN
What HN people wrote when they linked it
ellanuutinen · 2018-08-02
Reaktor | Software Engineers | New York, Amsterdam, Helsinki, Tokyo, Dubai | ONSITE | https://www.reaktor.com
We’re looking for great engineers with diverse backgrounds. We need people that can fill hybrid roles with different emphases on the wide context of product development. We don’t have predefined positions: instead, we invite you to come talk to us about your skills, experience, ambitions, and dream role. We hope to find exceptional people to do exceptional work with us, and we believe it’s important that we define your role and path to our mutual growth together.
Reaktor is a hybrid partner for all things future. We reimagine businesses, and we design and build tomorrow’s digital products together with clients such as HBO, Viacom, Finnair, Supercell, and Michael Kors.
Apply via our careers page: https://www.reaktor.com/careers
Nokinside · 2017-10-20
Finnish software company https://www.reaktor.com/ has offices in NY and they offer basically the same benefits as people in Finland have. Especially vacations (four weeks guaranteed), parental leave and no too much overtime.
(Reaktor has been selected as the best place to work in Finland four times a row)
sarukuku · 2021-06-02
Reaktor | iOS Developer | Amsterdam, Netherlands | Visa + relocation | https://www.reaktor.com
More information and application: https://www.reaktor.com/careers/ios-developer-amsterdam/
At Reaktor, we design and build tomorrow’s digital products. We are known for our flat hierarchy, have a 5-star Glassdoor rating, and launched a satellite running Node.js in low Earth orbit.
The Amsterdam office has a unique vibe, being a lively mix of 20 nationalities. From day one, our growth philosophy has been to hire any and all Reaktorians out there. This has served us well, with a welcoming community of humans who will connect with you beyond the day-to-day.
Ideally you…
- Know how to write decoupled, easy to maintain and testable code in Swift.
- View your colleagues and clients as individuals with their respective strengths and weaknesses.
- Can work with the team to decide the best tools for the job at hand. Sometimes RxSwift is your best friend, and other times React Native suits a project better.
- Enjoy working with juniors and seniors on the shiny and dirty bits of a project. You might help out developing microservices or APIs for an app every now and then.
- Have experience publishing iOS apps to the App Store.
- Appreciate the fine details of visuals, user interaction, animations, and everything else that makes an app not just work but feel great as well.
alexnechayeva · 2021-06-02
Reaktor | Software Developer - Technology Agnostic | Amsterdam, Netherlands | 42 - 70k | Visa + relocation | https://www.reaktor.com
More information and application: https://www.reaktor.com/careers/software-developer-amsterdam/
Reaktor is a creative technology consultancy for forward-thinking organizations with offices in Amsterdam, Helsinki, Stockholm, New York and Tokyo. From premium software development to digital transformation, our global community of experts does it all.
As a Software Developer, you will be applying your tech skills in different domains and finding new ways of solving complex problems with your teammates.
What are we looking for?
At Reaktor, we are not looking for a work title, we are looking for a personality.
We know that good developers can create great things in any language so we have no hard language or tech requirements.
Ideally you…
- View your colleagues and clients as individuals with their strengths and weaknesses.
- Can work with the team to decide the best tools for the job at hand. Sometimes it’s Clojure running in a Kubernetes cluster, and sometimes it’s a small piece of JS running on AWS Lambda.
- Enjoy working with juniors and seniors on the shiny and dirty bits of the codebase. No ivory tower architects here.
- Have 3+ years of experience or maybe you’ve gotten a lot done in a shorter period.
omahlama · 2015-05-21
In my previous job at the Finnish software consulting company Futurice (http://futurice.com), there was a long discussion about this that ended with a volunteer-based publication of peoples salaries - around half of the 200 people opted in. The result was a bit anti-climatic: peoples wages were consistent and fair, no big drama.
After switching jobs to another software consulting company Reaktor (http://reaktor.com), I brought up this topic and the discussion was very similar. I decided to try a different route: I created a wiki-page called "Voluntary salary information" and added my name and salary to the top of the page. I then wrote a post to our discourse board explaining why I thought this was important. As of now there are 68 names on that list ( with only 1 obvious troll ) out of about 300 employees. Our head of HR replied to my discourse post with a detailed explanation of how peoples salaries are decided. Overall a great day for transparency.
juhohei · 2019-05-01
Reaktor | Senior Software Engineers | NYC | Full-time
Reaktor is a strategy, design, and engineering company based in NYC, Helsinki, Tokyo and Amsterdam. Our New York office is growing fast and we're always on the look-out for the most talented software engineers to make sure our teams are filled with best in class individuals. We might all have climbed far up the career ladder in our past lives, but here we leave our titles at the door and work together to get shit done with clients like HBO, Michael Kors, Nasdaq, Samsung, Supercell, and Finnair.
You can find more information on the role here: https://www.reaktor.com/careers/senior-software-engineer/?utm_source=H…
vickychijwani · 2016-09-06
The author answers this in the comments [1].
> Functions are also first class objects with observable identity, just like any other object. Identity can be observed in many ways, for example by doing an equality comparison or assigning a property. In the first example optimization is indeed possible as it's easy to see that the functions cannot be used for their identity. Optimizations have maintenance costs however and if similar simple scenarios are not common in the real world the optimization might not be worth implementing.
[1]: https://reaktor.com/blog/javascript-performance-fundamentals-make-blue…
sspross · 2015-12-16
OT: I'm wondering what that big screen in the back of the header video on their company website is for and how it works. http://reaktor.com/
ivanmanolov90 · 2017-01-12
Reaktor | New York City | Full-time | Senior Software Engineer| https://www.reaktor.com/careers/senior-software-engineer/
Reaktor is a strategy, design, and engineering company based in NYC, Helsinki, Tokyo and Amsterdam. Our New York office is growing fast and we’re always on the look-out for the most talented software engineers to make sure our teams are filled with best in class individuals. We might all have climbed far up the career ladder in our past lives, but here we leave our titles at the door and work together to get shit done with clients like HBO, Michael Kors, Nasdaq, Samsung, Supercell, and Finnair.
Here’s what we can offer you:
- Teams that are totally autonomous and cross-functional.
- A community of amazing people who will both teach you and learn from you.
- Experimentation and continuous improvement of our skills and ways of working.
- A commitment to constant evolution (and the occasional revolution).
- A world without hierarchy—big ideas can come from anyone and anywhere.
- A ton of fun!
What We’ll Expect From You:
- A ton of skills and wisdom in working with tech that you consider useful. In no particular order, here are some things many of us like: functional programming, Node.js, Clojure, React, Swift, SQL, NoSQL, general bleeding edge stuff.
- Passion for:
- Agile and lean principles that actually work – not rituals for rituals’ sake.
- Solving really hard problems (and doing it with clean code).
- Learning, growing, and…
marknadal · 2016-03-04
For anybody who found this interesting, make sure to read his earlier article (which he links to) here: http://reaktor.com/blog/why-csp-matters-i-keeping-things-in-sync/ . It sets up the problem which he then answers in this post.
We've been having a similar issue, where we want to make sure our data syncs correctly. One of our contributors built this ToDoMVC app http://todos.loqali.com/ (which basically also works for a grocery list app as well), but how do you know it synced correctly? Or more importantly, how do you prove it?
The article is great at addressing this with clojure and and CSP. But it would be nice if we had a generic testing framework (like Jasmine, Mocha, etc. are) for doing this. That is why one of my employees is working on https://github.com/gundb/panic (in development! not working yet!). So far it has been specific to our project, but this next iteration he is splitting it out and making it generic to any project.
You write your test, it gets deployed on a bunch of clients/peers, and then the test coordinator (panic) aggregates the results and confirms if everything ran correctly or not. The cool thing is since your test is deployed across a bunch of peers, you can have the test assert that client1 received an update from client2 - if that never fulfills, then it is considered a "fail". If however, a non-deterministic network hiccup occurs (versus a simulated one in the test), the whole test suite should bail and force you to re-run so you don't get…
betaby · 2022-01-22
Very relevant https://www.reaktor.com/blog/why-ive-tracked-every-single-piece-of-clo…
Why I’ve tracked every single piece of clothing I’ve worn for three years
hellofunk · 2019-05-15
I see everyone in this thread reference CSP [0] and I keep thinking they’re all talking about the foundations of core.async or Golang.
[0] https://www.reaktor.com/blog/why-csp-matters-i-keeping-things-in-sync/
fbn79 · 2019-01-15
Ok, well done! BUT.... Now port it to something you can really trust like Reason ML. See https://www.reaktor.com/blog/fear-trust-and-javascript/
larry_pi · 2015-12-16
It's a huge multi-user touchscreen. Nasdaq's got one as well: http://reaktor.com/work/nasdaq/ We (I work at Reaktor) use it to keep tabs on our projects and see who's doing what: http://multitouch.reaktor.com/visual-asset-management-tool
The actual screen is built by Multitaction (http://www.multitaction.com/) and Reaktor creates custom software for it.
zoenolan · 2022-03-30
Other are not wrong in saying Memory mapped IO. taking a look at the Amiga hardware Reference manual [1] and a simple example [2] or a NES programming guide [3] would be a good way to see this in operation.
A more modern CPU/GPU setup is likely to use a ring buffer. The buffer will be in CPU memory. That memory is also mapped into the GPU address space. The Driver on the CPU will write commands into the buffer which the GPU will execute. These will be different to the shader unit instruction set.
Commands would be setting some internal GPU register to a value. Allowing the setting resolution, framebuffer base pointer, set up the output resolution, setting the mouse pointer position, reference a texture from system memory, load a shader, execute a shader, set a fence value (Useful for seeing when a resource, texture, shader is no longer in use).
Hierarchical DMA buffers are a useful feature of some DMA engines. You can think of them as similar to sub routines. The command buffer can contain an instruction to switch execution to another chunk of memory. This allows the driver to reuse operations or expensive to generate sequences. OpenGL's display list commonly compiled down to separate buffer.
[1] https://archive.org/details/amiga-hardware-reference-manual-3rd-editio…
[2] https://www.reaktor.com/blog/crash-course-to-amiga-assembly-programmin…
[3] https://www.nesdev.org/wiki/Programming_guide
dpatty · 2020-06-13
Here is the RSS feed: https://www.reaktor.com/feed/
siruelise · 2019-06-11
Reaktor | Software Developer, from World to Amsterdam | VISA, ONSITE
We: engineering and design company, located in Amsterdam, 12 nationalities strong, 18 years old. You: a gifted developer, not necessarily located in Amsterdam, whatever nationality or age, interested in seeing what the land of tulips has to offer.
Reaktor is looking for software developers to join our team in Amsterdam – wherever you might be living now.
From day one, our growth philosophy has been to hire any and all Reaktorians out there. In order to help newcomers from abroad ease into Dutch life as smoothly as possible, we have now published our very own Relocation Guide: https://relocate-to-amsterdam.reaktor.com
What we expect from you:
– A ton of skill and wisdom in working with tech that you consider useful. In no particular order, here are some things many of us like: functional programming, Node.js, Clojure, React, Swift, SQL, NoSQL, general bleeding edge stuff
– Ability to read and speak English fluently and idiomatically
– Appreciation for agile and lean principles that actually work, and solving really hard problems with clean code
– Willingness to be responsible for your work, development and career path
What we’re offering to you: https://www.reaktor.com/careers/software-developer-from-world-to-amste…
(All open roles: reaktor.com/careers/amsterdam)
Drop us a line: [email protected]. <3
muraiki · 2016-03-24
I've prototyped UIs with RxJS (the javascript version of reactive extensions) both by itself and with Cycle.js. I've also used reactive programming in Perl 6. There are a lot of things to like about reactive programming, but anymore I'm not sure if it's the right answer. Let me first preface this by saying that I'm building upon thoughts presented (by someone else) here: http://blog.paralleluniverse.co/2015/08/07/scoped-continuations/
One problem with reactive programming (and also with promises), is that you are essentially using monadic composition in an imperative language. Because of the lack of special support for monads that you have in a language like Haskell, you have.to.chain.flow.control.methods. As a result of this, you lose access to the standard flow control the imperative language provides you, and you also generally end up with mangled stack traces. Now I know that rxjs5 is working on the stack trace problem through the usage of a recursive scheduler, but I'm not sure how this works on the Java side of things.
An alternative approach can be found in languages like Go and Erlang. In these languages you generally do not need to worry about exhausting a thread pool because they have made creating "threads" extremely cheap. As such, you can write normal imperative code that blocks, potentially indefinitely, and also still preserves stack traces and which uses the plain flow control structures (and error handling) of imperative programming.
Furthermore, if you…