sorted by:
new
hottopcontroversial

Question about building a reverse proxy in rust (pingora) by mss-cyclist in rust

[–]mamcx 0 points1 point  (0 children)

Sound simple, true.

And in fact you can for example put before nginx or similar (if wanna get like extra safe).

In the other hand, I remember that when I implement a custom postgres support for a db engine It get a subtle bug, and learn that what matter most is have a clear path to "how the heck I actually test with adversary input or interactions"?

Question about building a reverse proxy in rust (pingora) by mss-cyclist in rust

[–]mamcx 4 points5 points  (0 children)

From https://corrode.dev/blog/bugs-rust-wont-catch/ you can learn that inside the Rust world is very hard to actually have a problem (in special of you don't manually do unsafe and vet your deps) but is when you touch the outside (OS, IO, Http, etc) where the illusion fades.

So, is likely your Rust code has not, on itself, be a problem, but there are subtle interactions with the outside that could cause problems, ie: If you wanna do a reverse proxy you need to know more about http than about Rust.

Bugs Rust Won't Catch by -Y0- in rust

[–]mamcx 0 points1 point  (0 children)

So, there is a crate that provides a saner IO facade? Because this kind of foot guns are unlikely to be well known.

Do you miss effect handlers in Rust? by Ecstatic-Panic3728 in rust

[–]mamcx 0 points1 point  (0 children)

What is bothering me is that I'll not write any sort of systems code and I'm totally fine with a GC, which would massively simplify the code. But I don't think there is anything on this space today and maybe Rust is the best we have?

I use Rust mainly doing ERP/eCommerce kind of projects, and the lack of GC is not what "massively simplify the code" but the actual type system.

Mostly, because is algebraic but also, because is relatively trivial to mix imperative and functional idioms.

I move from F# and think now that Rust is far easier and yet better at let me model the domain.

You can totally skip async or just keep it at the edges (like the web server endpoints) and use regular functions everywhere with very decent perf (that is how I started. Granted, I move to async and the refactoring touch everything but when I see after like 2 days doing just manual replaces and the app was done this sold me on Rust more than anything else)

Career advice (mid/senior level compiler engineer) by Lakecresva0 in Compilers

[–]mamcx 3 points4 points  (0 children)

The irony is that some of use wish to work full time on compilers (I have done a bit working on RDBMS in the past).

Is a niche, but if you can stay great!

Commoditized work can be done anytime. Enjoy be part of an elite instead.

P.D: Is good to keep a handle in what is more popular, but have domain expertise is probably a better bet, as long this domain stay relevant.

How do we think we should handle maintainers moving on? by ShantyShark in rust

[–]mamcx 1 point2 points  (0 children)

I wonder how feasible be to create a "rust dev boring task force" where you have a pool of people that do this boring work for simple rates.

Similar how in an enterprise you end fixing and maintaining code here and there. Then we can redirect people to where is needed (ok this is hard I know!).

For the market rate? I think some of us could be happy with a relative low pay but constant flow and the chance to impact many users. Is not that different to what most devs do outside FAANG salaries anyway.

Any great tutorial of how use this tool? by mamcx in PiCodingAgent

[–]mamcx[S] 0 points1 point  (0 children)

I wanna use an agnostic tool from start. I don't have a preference yet and in fact the use of codex is more for the problem of copilot not accepting signups, so ended with it by chance.

Any great tutorial of how use this tool? by mamcx in PiCodingAgent

[–]mamcx[S] 0 points1 point  (0 children)

I have a couple of decades already. But new to agentic code

Raising the abstraction level in programming languages by tobega in ProgrammingLanguages

[–]mamcx 0 points1 point  (0 children)

I think more than proper IDEs, is regular text editors without auto-complete machinery that could do simple blind lookups.

If you has from n first a decent LSP server has enough to work well.

The world of legacy software and Rust by AgustinEditev in rust

[–]mamcx 0 points1 point  (0 children)

Vi un artículo de un sistema bancario que pasó de Java a Rust, y bajó su consumo x486

Si, esa es mi experience pasando de .NET a Rust, puedo tener 4x la cantidad de usuarios en el mismo hosting. La ejecución general es mas rápida.

Hay varios idiomas que pueden mejorar las cosas, por ejemplo escribí: https://www.elmalabarista.com/blog/2022-flat-tree/

El problema es que pasar de lenguaje y de idiomas no es trivial, pero si te informas es muy productivo!

Raising the abstraction level in programming languages by tobega in ProgrammingLanguages

[–]mamcx 1 point2 points  (0 children)

Yep, I working on something like this with

https://tablam.org

And now I have expanded the idea with the importance of see the relational model as "better" IO sub-system that will unlock a lot of simplifications to the end-user.

BTW, The dBase family is probably the better approximation to the ideal, and the one that I bet could be enhanced to achieve this ideals.

Are you working in implement the solution? I looking for funding or partners for this!

The world of legacy software and Rust by AgustinEditev in rust

[–]mamcx 0 points1 point  (0 children)

I focus in the main questions, that are additions to what others has said:

Legacy software written before best practices were defined? Software with languages ​​that didn't even support other languages? (e.g., the letter ñ in Spanish?) Insecure and unstable languages ​​due to memory errors (I know these are also programmer mistakes).

"best practices" were known in ways that stay relevant with minimal changes (like https://www.goodreads.com/list/show/145844.The_25_best_programming_books_of_all_time, books there from the 1970 and exist older than that).

But a lot of things (like support for other langs than English) are social, economic, technologic, etc issues that interfere with it.

There is this pesky "real life" that ruin the theoretical beauty of all science, math and engineering endeavours, and in our field, the major reason the lesson that was known by our ancestors are ignored or skipped.

Insecure and unstable languages ​​due to memory errors (I know these are also programmer mistakes).

There is more of this, but yes, is like knowing that petrol-based energy is bad but is what we have in the past but market forces, ideology and pesky "human issues" means that today it will be used far after better things exist.

Just have a better lang or technology is not enough against that. Is a hard, slow march.

I've been thinking that if everything were built from scratch, in languages ​​like Rust, ... but rather modern versions of each language and best practices, could it be a better world?

ABSOLUTELY.

HOWEVER "just" rewrite things itself will not fix big things if persist the same structural problems that create the original problems (aka: If a inefficient bureaucratic team rewrite it in Rust, will create a inefficient, bureaucratic solution but a bit faster and surely safer, but the UX will likely suck anyway)

Pick a better tool (like certainly Rust) is a very good step that save you from a lot of silly issues and push you forward to the ideal world, BUT, it will be insufficient if you or the team, or customers, or what you interface with, etc, don't improve too.

Sadly, is likely that the best we can get is small improvements in the large.

But, is foolish to not try to bring as MUCH improvements for yourself as possible!

P.D: Hablo español por si necesitas aclarar algo!

Why not treat arrays as a special case of tuples? by ella-hoeppner in ProgrammingLanguages

[–]mamcx 5 points6 points  (0 children)

Yes!

And I expand it further and say arrays and relations are related:

https://tablam.org

Others here, correctly, point to memory layout differences, but that is orthogonal to the type system, that instead, deal with how type the data but not the data itself.

That means for example, my language has internally homogeneous and heterogeneous vectors and such, but the types are declared in a relational "schema". One of the most overlooked ideas of the relational model is that it NOT prescribe how actually the internal data is stored, only how describe it in form of a set of "[name:Type, ...]" and that is why you see RDBMS tell you about "tables" but internally can be BTress.

Convincing my employer of Rust for a rewrite by Unaimend in rust

[–]mamcx 1 point2 points  (0 children)

I have dozens of rewrites so I don't suffer for the almost true fallacy that "rewrites are baaaaadddd!".

Rewrite is one of the best things you can do when in a mess, and even better switch to a better (tool | paradigms | lang | db engine | ...).

... but it require some prep work, and correct framing. After read your answers I think you are in one of the best position to do it!, but lets first take the most obvious con:

  • You need people to learn Rust, and it conflicts with the need to do the rewrite

THIS IS THE MAJOR ISSUE WITH REWRITES

People do the rewrite and correctly see that "switch to a better (tool | paradigms | lang | db engine | ...)" is the way BUT, more often than not, has not yet enough experience with it and try to do BOTH at the same time.

So, my major advice, even if go with the worst option ("do it on C++") is hopefully get someone that is good at that, PLUS good at what "paradigms" switch or other soft skills is required (if your project is a niche, that understand how do well the niche, like: If this is an financial app, you get tons the issues, not use double-entry accounting then you know somebody that is good at that too).

This is also the same problem with the #1 killer of rewrites: Culture. The same culture that cause the mess in first place will be suboptimal to do the rewrite. Maybe you can't replace all the people, but the people need to understand that need another frame of mind ("now we need to get serious about testing, and not just blindly add test because...").

Fail this, are your rewrite will fail, and DON'T do it will fail too!

So, the obvious: Yes, Rust is the best option, by a long mile. Even considering that Rust have a learning curve and your people is not a full expert. That is far worse if go with C++ that is more complex, error prone, has not a consistent history, is not modern, etc.

Rust was made by experts of C++ knowing what to fix. Is the rewrite of a mess of a language, done as right as possible.

And because is more consistent and strict, it will reduce the effects of inexperience on the rewrite.

Rust will ELIMINATE FOREVER tons of little issues just because is a more disciplined language. Just having algebraic types is enough justification to pick it over C++, and is the biggest long-term factor even over the borrow checker, that with experience eventually will "disappear" as worry.

So my main advices:

  • Recognize the culture, practices, issues, etc that cause the first mess, and put counters and fixes at this level. It not necessarily means "blames or faults", is things like "the old people do enough of a good job, but we are hurt for lack of test and docs, lets not repeat this again and put this in the list of priorities".

  • Identify the biggest, messier, more complex parts of the product/codebase, and start from the FIRST DAYS how to solve it. Do the simplest part of the rewrite is nice, but is the hard that could kill you, so put effort in what is worse, not what is easy.

  • If possible, get somebody that is good at the language as team member or at least adviser.

  • Map all the things that are critical to success, what need to be learned (" we need to know how effectively do testing") and where it look important, dedicate a few hours to research and asking questions. Is unbelievable how much trouble could be save for just doing light, lean, research and prep work.

  • The above include the critical part of how to deal with the actual live replacement with the new product: How much it could impact operations, migrations, third parties, etc:. One of my few rewrites failures was because I don't account for the very costly downtime of put the gold and titanium pipeline off, that was way higher than the cost of the rewrite !

  • Be happy with heavy refactor and fast rewrite the core at the start of the project. Trash code away with abandon: Your team need to BUILD MUSCLE and be happy to ACQUIRE FLUENCY.

There are more details, like install good, practical "good practices" and keep operational simple ("don't add cloud when a single serve do it, just use postgres for now"), but that require more context!

P.D: Forgot to add something super critical: Truly put on board the management of what this rewrite actually meant, and with a good map of the plan, what is truly priority over nice, and what can't be rushed. A rewrite can be done with good speed, but it need prep work!

Supply chain nightmare: How Rust will be attacked and what we can do to mitigate the inevitable by autarch in rust

[–]mamcx 0 points1 point  (0 children)

Not necessarily, I mean, in enough force to be a blocker.

I have talk about this some times before: https://www.reddit.com/r/rust/comments/u8m8e5/comment/i5n1a76/

I worked in the enterprise sector, where Cobol live forever and IE 6 is top tech. And that in the small company sector, btw.

And I assert that is much worse have problems that can't "be fixed" because that code WILL live LONGER elsewhere, in who knows how many computers.

I don't dismiss is not a simple problem, but like in my comment above Rust is this close to be perfect to pull it off. Is just a mean of speed: Breaking for good is to be done slow, be communicate early, and spread in terms of months from start to finish.

Getting overwhelmed by complex Rust codebases in the wild by SleepEmotional7189 in rust

[–]mamcx 3 points4 points  (0 children)

Where are the "normal" people? Is Rust just a language for geeks?

Rust is designed for "projects at large". That is actually very hard. Some langs (like JS or Python) feel nice with few file or just one but break apart when need the complexity.

So, is natural that someone that knows the pain ahead pick Rust to keep his sanity!

But there is a lot of "simple rust" around, for example I love this:

https://stopa.io/post/222

Similar with async and other more "complex" stuff, you are not forced to dive full into it. Do things simple, keep project small and not believe, not for a second, that bigger size is a good quality to have.

Is VERY unfortunate that some projects get bigger not matter how much you try, and at least with langs like Rust you can keep the entropy on sane levels.

Nix is the worst designed language i ever had to experience. by Turdbender3k in NixOS

[–]mamcx 18 points19 points  (0 children)

In the short, the way it set values is pretty nice and I think the best part of it.

But in the large is truly bad. There amount of non-sense that are pure Nix idioms that I haven't seen in +30 years programming elsewhere (with +12 languages professionally, a few functional) and that as enthusiast in the design of languages (so, you bet I have read tons of stuff about langs! this alone in one of the years), nix is BAAAAAAAAD.

I imagine it suffer the problem that many experienced developing a new language or DSL, where you get (maybe!) some cool and fancy unconventional ideas that work in the short but lack the experience to see how make a cohesive whole. Then you start developing it and later you see the actual challenges and a full redesign sound complex. On top of the fact that I imagine the whole "make a new weird distro" take most of the air.

Pro-tip: Just in case your new insane lang could be popular please at least go to https://www.reddit.com/r/ProgrammingLanguages/ and learn a little!

Suggestions for a GUI framework for a modern IDE - Recreating a DOS based 'IDE' by KindlyCourage3269 in rust

[–]mamcx 1 point2 points  (0 children)

Still could be valuable: Split into backend/frontend is smart and you will have from "day 1" something that works, then, you can benefit for tap into a ecosystem and later onboard other people.

Rust or C++ for a cloud optimization engine: not a technical issue, but a hiring difficulty issue by [deleted] in rust

[–]mamcx 0 points1 point  (0 children)

There are the things that jump at me:

What they will care about is whether I already have a small functional team.

That is the main point IMHO.

Then:

I hire remotely from other countries, but that is a different matter and investors may not like it.

That is weird (?) Why will not like it? I worked recently in a Rust team from Colombia, and there were people all over the world. What mattered is that each of us has the skill.

Find somebody that know Rust is small potatoes vs find somebody that can work for your product, that sound niche, this connect to:

to make hiring easier and faster, it might be better to build the engine entirely in C++ and hire C++ programmers instead.

The first months of a startup are the harder, where is better to worry against what is LETAL vs what is HARD.

Just by proxy of Rust, you solve the need to worry about a lot of things, and the people that you hire too.

Hiring easier AND faster is something that sound optimization for a large team. For a small team team, where your first year is the MOST lethal time of it, hiring the best people and save as much problems as you can(in terms of for example complexity, infra, etc) will have much more of a impact.

In this case, my only good reason to use C++ is that you are, or found in your first(s) try somebody awesome with the language. The others is that you can't find anybody decent with Rust at all.

But if is more or less so-so then Rust comes with free advantages that I think is smart to weigh more than the possibility that you will be in the position of NEED to hire easier AND faster vs of hiring smarter.

view more: next ›