mdtusz

I may be biased from my past experience, but graphql tends to make codebases a nightmare if you aren't the one that initially set up the system and abstractions - it's (IMO) unnecessarily complex and blurs so many boundaries with a pretty poor tradeoff when compared to "normal" APIs.

After Rust, I think typescript is my favourite language to write these days because of how expressive the type system is - my only complaint is that there's no clean way to bind an interface implementation to a pure data shape like you can in rust and you're forced to either use classes or some sort of DIY binding to an object prototype.

As long as types are kept simple (i.e. avoid weird type tricks unless you actually need them) debugging is usually fairly straightforward assuming you have appropriate tooling setup with your editor/ide.

My biggest gripe with Go is that I find myself wanting more expressivity - not just to minimize boilerplate, but to constrain the data flows and how parts of the code are allowed to fit together.

AON3D (YC W17)| Montreal or Remote within N.A. | Full-Time | https://www.aon3d.com

AON3D is a Montreal-based additive manufacturing hardware, software, and materials research company focussed on solving the hardest problems in 3D printing, and developing tools to make better and stronger end-use parts using advanced materials. We believe that there's plenty of room for improvement in 3D printing - particularly in the software domain - and are looking for people to join our RnD and product teams in developing geometry processing and engineering workflow tools.

Open software roles:

* Frontend Engineer (typescript, react, WebGL) - Building the interface for working with 3D models and materials characteristics. UI/UX experience a big plus.

* Backend Engineer (rust, k8s, docker, redis, postgres) - Developing and maintaining a web service, workers, databases etc. Backend stuff with a sprinkle of geometry.

* Computational Geometry Engineer (rust) - Geometric analysis and 3D model processing. FEM and simulation experience or materials knowledge is _extremely_ helpful here too.

Open design role:

* UI/UX Designer - This role will be integral to help guide our product, brand, and design language moving forwards

All roles are mid to senior level and have tons of room for growth. Remote works for us too, as long as you're willing to travel now and again to meet in person! Email me directly to miklos@aon3d.com or apply to the relevant posting at the link below, and please note in your application that you saw the post in this HN thread.

https://www.aon3d.com/careers/

The presence of a keel isn't necessary - just righting moment. If you look at most very large sailing ships, their keel isn't a large protruding fin keel like on racing boats like you're imagining. A cargo ship has enormous righting moment just by means of its ballast - the windage of their hulls alone is enormous.

I still don't think using traditional sails is practical though, and kites are a far more elegant and useful solution. They require far less cost and are easier to retrofit onto existing hulls, can be easily scaled up or down depending on wind conditions, and in the event of even catastrophic failure are pretty safe (i.e. if the kite line were to break). The biggest danger of them is the kite line falling in the water and getting fouled on the propellers, but this is a solvable problem.

I think your comment emphasises the importance of good function and variable naming. I've read some incredibly clear and obvious C code and some incredibly hard to understand Python code that both do the same thing - it basically all comes down to the naming choices used. `TAX_RATE_WY` would be far easier to understand and maintain (especially when seeing other state abbreviation suffixes nearby) and has the added benefit of using the same `TAX_RATE_` prefix for _all_ similar values so is much easier to pick up on when scanning through the code.

The science of reading and literacy would likely be a very valuable course to teach in CS programs.

What happens when you buy a used laptop?

There's inherent risk in buying a device from a third party that you may not fully trust, but that risk is in the hands of the buyer to assess, and to mitigate as appropriate. When the average person buys a used laptop from Craigslist, I doubt they're doing a full disk wipe and reinstalling the OS, and they're definitely not verifying the bios or other motherboard-level code. There shouldn't need to be some special case applied for tablets or laptops either. They're all just computers.

Wherever you have a firehose of data that needs to be processed.

I've heard of it being used as a sort of message queue for application level events before, but that sounds like a nightmare of trying to reinvent the actor model with 1000x the complexity.

Congrats on the release folks!

I'm always impressed by how far the library has come while remaining _so stable_, and it's always the thing I point to when talking about backwards compatible and stable JavaScript API's.

I bet you're all happy to be finally dropping that polar chart!

Rather than centralizing on GitHub, this seems like something that could be well suited as a `.well-known` url websites/companies could use, then anyone/everyone could aggregate or just inspect what is being used.

I hear this argument a lot, but the reality is that most devices that need realtime support will either be using the rt patched kernel, or be using application specific mcu's that handle real-time constraints while the Linux system just acts as the main control hub and orchestrator.

Check out tide. It's still very early days for it, but is in my opinion the easiest to use and I'm betting in the long term will win out as the "express" of the rust world. It has very straightforward routing and middleware semantics which covers the majority of the "base" needs for most web server backends.

I sometimes look back in awe and wonder at how good bonzi buddy was for it's time as a _piece of software_. It was objectively ridiculous and borderline a piece of malware, but it's burned into my memory and it's functionality was fairly impressive when compared to buggy toolbar apps of today.

A similar thing I've noticed a trend of recently in frontend react codebases is overuse of memoization. It seems as though people don't realize how it works and that it is often _less_ performant than just doing some low cost computation on each render (like a comparison or basic math).

RAF is still imprecise for audio use. For audio in the browser, you usually want to defer all timing events that must be precise to a scheduler that uses either the webAudio context time or even more ideally, use a lookahead scheduler to schedule events by audio frame using an internal counter and the sample rate.

A great programming exercise that forces you to wrap your head around JavaScript timing events is writing a small step sequencer that can be used while it is running with minimal latency.

I've always liked an asymmetric layout when working with two monitors such that I have one "main" monitor in front used for my main task (e.g. my terminal for work) then a secondary to the side that is used for supporting windows - browser, music, pdfs, or another terminal depending on the work. It helps keep an established hierarchy, and you basically just use your neck as a window switcher.

I have the same experience.

I was given a MacBook pro at my last job and had to request a ThinkPad after a few weeks - the lack of function keys alone was enough to drive me mad, but countless issues with docker and even homebrew pushed me over the edge. For context, I _used_ to be a hardcore mac fanboy and did all my development work on it, but the macOS of today doesn't feel the same as the OSX of yesterday - at least not to me.

Linux desktop environments definitely still suck, and there's always some quirks with hardware but for the work related tasks once it's initially set up, it's always rock solid.

It appears to be using an 1/4" patch cord, not an XLR cable! XLR is the cable (and connector) with 3 pins as is used with microphones and carries a balanced signal - 1 leg is ground, then the other two are inverted signals to minimize noise.

This seems like a particularly strange reason to not try their service and to me is akin to saying "I won't use CarRentalCompany because they require a credit card. What if I'm new to driving and total the car by wrapping it around a tree?"

If anything, this is just AWS being overly generous and forgiving.

This seems quite interesting and powerful for what most server-side rendered websites need from javascript, however the _usage_ seems fairly klunky to me at this stage.

I could see this being a joy to work with though if a well determined usage pattern emerges where you have something like a `some_page_template.html` file open next to a `some_page_hyperscript.hy` where you define all the locally scoped functionality and the two are combined by your webserver template engine.

It wouldn't be very hard to set up, but having a de-facto way to structure and organize things it would likely help with adoption and prevent new users from being architechture astronauts.

Yes, but also no.

More granular browser API permissions would be fantastic, but the current interface for grant/deny in all the major browsers is annoying enough as is. The prompts need to be moved to a less in-your-face place, or at least have the option to be. I almost always find myself clicking "deny" because no, I don't want to give your recipe site permission to show notifications.

Somewhat related is the new "sign in with Google" prompt I've been seeing on lots of websites. I accidentally clicked it when visiting the Seattle Times website and have been working inundated with spam emails even after clicking unsubscribe.

And both methods are bad.

Whiteboard tests aren't inherently bad, but the sorts of algorithm questions that are asked at some interviews are absurd and do practically nothing to determine whether the candidate would be a good employee. 95% of being a programmer is plumbing data together, and it's pretty rare that there is a need to develop more complex algorithms for things - as long as someone knows the concepts of time and space complexity and isn't going to make huge O(n!) operations, it's much more important IMO to be interviewing for communication skills, system architecture, network, and security knowledge.

There's obviously exceptions to this if you're hiring for a role that specifically is writing very algorithmic code to solve a hard science or graphics problem but that's very much the edge case and even if it is the case, domain knowledge will be more important.

The "pro" models exist - they're just not Pi's.

Industrial IoT does use Pi's a fair bit, but this is IMO a misuse (I'm guilty of it too) and in the long term can be a disservice. The Pi is a great platform for a go-to-market product, but they have many shortcomings that for most use-cases in industry are showstoppers (most notably, Pi's will often fail without warning, or their "disk" will become corrupt). More expensive industrial products are out there and typically are more robust, and designed in a way that they can be more seamlessly integrated to a product - once the upfront costs are paid (both in development and dollars).

What really needs to happen is other manufacturers making the development on their hardware more straightforwards. What the Pi foundation has done is shown that companies and developers want to just be able to run a widely available and minimal linux distribution and not have to muck about with proprietary and poorly documented SDK's behind closed doors.

Pollen seems so incredibly cool and powerful, but every time I have tried to play around with it, I get distracted by small quirks and areas that I wish were documented more clearly, or in a more organized format.

My daydream is to make a _good_ technical documentation system with it that is usable by the everyman, but it's still just a bit too much of a stretch. Markdown + pandoc + LaTeX templates get close, but LaTeX templating is a nightmare, and markdown is far too limiting and lacks expressivity (without ad-hoc DSL's slapped on top).

If anyone has a good pollen tutorial or example repo, I'd _love_ to know of it.

Solvespace is incredible for those with a more programmer-y mind and workflow, however it lacks more "advanced" features that sadly don't seem to have any momentum for implementation (at least last I checked) like chamfers/radiusses, helixes, and some other navigational and organizational features.

It's a fantastic platform though and I encourage all engineering/CAD nerds to try it out. It bridges the gap between writing OpenSCAD and using a full fledged CAD software perfectly.

It's not a bad thing for these to get posted. If anything, it highlights how technically illiterate the powers that be really are.

It's all too easy to assume that everyone knows what http requests are and how a browser works when working in the tech industry, but the _vast_ majority of the population has no idea whatsoever how the (modern) technology they use and depend on works, on even basic levels.

Most people understand that when you phone someone, it has to go through a telecoms company. For some reason, the internet doesn't have that same understanding and people are still stuck with this idea that browsing to a website is still just a two-party transaction between them and the website they visit.

Especially with additive manufacturing, SDF's are far superior but still not widely used (but I predict this will change very soon). As others have said, many operations are much easier when working with SDF's, but specifically for AM, there are many operations like lightweighting that are extremely difficult to do "correctly" when using normal meshes. For simulations as well, an SDF makes things like voxelization, random walks, and basically everything else that is related to the topology of a part much easier.

Check out the company/product nTopology. It's IMO the future for engineering modelling and CAD for AM.

I used to work for an AM company and was essentially the internal evangelist that complained about STL's and "traditional" CAD formats that are proprietary or just outright a PITA to work with (I'm looking at you, STEP...)

It really isn't all that complicated though, and just takes money to fix the urban planning mistakes that have been made in many metropolitan cities.

Montreal is probably the most livable "big" city in North America, and it's mostly because of three things:

1. Excellent transportation. The metro is for the most part consistent, extremely affordable (it's ~$85/month, and about half that for students and youth), safe, and works as a great mainline transport. Busses are also very frequent - most coming at most 15 minutes apart during regular hours, and usually every half hour or so past 1am. You can get almost anywhere in the city in an hour or less using public transit.

2. Renters are protected. The Regie Du Logement heavily favours renters in housing related disputes, and as such, the prices also favour renters. Most individuals pay $1000 or less in rent, for entirely adequate housing, and if they want to move, it's almost certainly an option.

3. Permissive zoning. With the exception of the downtown core, there are grocery stores and pharmacies everywhere. Combined with depanneurs (corner stores) being within 500m of just about any point in the city, you are never far from milk, eggs, bread, beer, wine, and other necessities. Combined with businesses themselves being able to set up shop nearly anywhere as well. Ground floor business with residential above is the norm for nearly all "main" streets.

Yes, there are difficult things for existing cities to recreate, but it is almost entirely due to poor urban planning choices being made by the municipal (or state/provincial) powers that be.

USD price does fluctuate and inflate over time yes, but the difference is that this is essentially an invisible effect on day to day life for anyone that is not doing forex trading.

The reason the US dollar is "stable" is partially due to the fact that it is backed by the US government. It is a requirement that businesses operating in the US accept payment in US dollars. Until somewhere mandates that bitcoin _must_ be accepted, it will never truly be a currency, the same way that gold is not a currency, and the same way that wheat, or potash, or shares in GME is not a currency.

There's also a concept of "sticky" prices that most economists are quite familiar with - this assists in keeping the price of a coffee stable, whether or not technophiles accept it or not. Even if the price of the US dollar fell by 50% today, your coffee would still cost you around $2 or $3 tomorrow (assuming the coffee shop was even open).

While typescript typing is extremely powerful and expressive, I sometimes find that code written with it overuses some of the features in order to make types and interfaces align, rather than rethinking the design altogether. Especially with generics, things can get overly complex precisely because of the ability to extract return types, use partial types, omit fields, etc.

My biggest typescript gripe is the fact that interface and type are _nearly_ interchangable, and many codebases just use interface wholemeal where it isn't really appropriate.

The way I always see it is that `null` is for known unknowns, and `undefined` is for unknown unknowns.

Explicitly defining something as `undefined` is paradoxical and IMO should never be done. I've tried to explain this concept to some co-workers without much lasting success, but it's a pretty common concept to other languages.

Undefined should basically never be used as a value directly.

The subreddit has ~65,000 weekly active users (ignoring this week), and the screenshots of "big" positions aren't that common, and often from the same accounts.

It's a bit disingenuous for people to make it seem like there's thousands of people putting their life savings and retirements into stocks - and even so, I would guess that many of the people who do claim to use "life savings" actually mean "the 10k I had in my bank savings account" because they're only 23.