Recent submissions

Comment · 8 months ago
Location: Brazil

Full Remote: Yes

Full profile is on LinkedIn: https://www.linkedin.com/in/eduardo-lemos-rocha-3198a5149/

Website: https://duing.dev/

Technologies: Haskell, Clojure, OCaml, F#, Racket, Erlang, LFE.

Email: [email protected]

I currently work with Clojure. I'm looking for a part-time contractor job (100 to 120 monthly hours) in a statically typed functional language. What type of place am I looking for? A place where people have my back, and they trust I have theirs; working around people who love what they do. The former builds trust, and the latter establishes a coherent vision within the team. There is nothing a team of engineers that trusts each other and loves engineering can't do when united.

Comment · 1 year ago
Location: Brazil

Remote: Yes

Full profile is on LinkedIn: https://www.linkedin.com/in/eduardo-lemos-rocha-3198a5149/

Website: https://duing.dev/

Technologies: Haskell, Clojure, OCaml, F#, Racket, Erlang, LFE.

Email: [email protected]

I currently work with Clojure. I'm looking for a part-time contractor job in a statically typed functional language. What type of place am I looking for? A place where people have my back and they trust I have theirs; working around people who love what they do. The former builds trust, and the latter establishes a coherent vision within the team. There is nothing a team of engineers that trusts each other and loves engineering can't do when united.

Comment · 1 year ago
Location: Brazil Remote: Yes

Full profile is on LinkedIn: https://www.linkedin.com/in/eduardo-lemos-rocha-3198a5149/

Website: https://duing.dev/

Technologies: Haskell, F#, Clojure, OCaml, Racket, Erlang, LFE.

Email: [email protected]

About: My fascination with computer science, with a focus on functional programming, will settle your project in peace, without any stress, extra working hours, and regret. Regardless of the tool and nature of your company, you will have in your hands something that works, performs great and you will be proud of how maintainable it is. You will want to frame it and hang it on your wall because of its elegance. End the pain. A quick email or chat will do.

Comment · 2 years ago
Comment · 2 years ago
Thanks for the ideas and references! I gotta say, though, that I will be pretty sad if having to write a custom protocol turns out to be the final solution. So much more convenient to use OTP (especially now that we finally have an infinitely extensible serialization library for it; Zerl). I'm shocked such an oversight would exist in a real commercial solution which is the BEAM.
Comment · 2 years ago
How can one protect the server then? Do we need some special behavior and/or library?
Comment · 2 years ago
Sounds like an awesome idea for when we introduce the Server Browser! Thank you!
Comment · 2 years ago
Please correct me if I say anything wrong.

As far as I can tell, this is not possible at all; the serialization layer (Zerl) cannot send arbitrary code to another node. Now, assuming we implement this, I also think this is not possible due to how the server is designed; based on supervisors and child processes for user sessions.

We recently became aware that you can indeed send tuples that have fixed effects when using the supervisor behavior, so it may be totally possible and probable that one could exploit this vulnerability to some degree in our server. We plan to investigate more about it as we continue to learn more about OTP and the BEAM.

Comment · 2 years ago
Given the current state of the game (the one we keep passing around between client and server), I don't think Erlang is a bottleneck in performance for us, and it won't be in the near future. Keep in mind this state is not that huge and it is yet not distributed, so it is totally possible that at some point Erlang will slow us down. I will keep your comment in mind, thank you!

Edit: currently with the game running at 60fps, there is no bottleneck from the server side. And we call it every 16ms! I should also mention that Erlang's choice has a learning purpose; we want to try to use the game as a way to learn more about OTP and the BEAM.

Comment · 2 years ago
No AI-based tools were used to make the lore. One of our developers (not me) is more of an intense reader and retro gamer; he was the one chosen to write it.
Comment · 2 years ago
Thanks, I will for sure take a look!
Comment · 2 years ago
We are using maps all over the place in the server, and so far nothing has been annoying.

I gotta say though that lack of infix custom operators for the monadic bind is a pain.

Comment · 2 years ago
We haven't touched the distributed part of the game, but our understanding is that when that time comes, it will be easier to use the BEAM approach given that it was made for this purpose.

Given the experience so far, it seems that using Erlang was the correct choice, not only because of the above, but also because Erlang made the server implementation way easier than we thought.

Comment · 2 years ago
Former case. Just testing things out. We will for sure have to either learn Blender and this ecosystem or find someone with this skill set.
Comment · 2 years ago
The main 3D part of the game is now on pause. We'll implement minigames (2D ones) leveraging all the current game's Zig and Erlang pieces. After getting that done, we may return to developing the main game.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton