Consider that as of (always and) 2026 you are held accountable for whatever AI-slop* you produce. Will that change within 5 years? The mindset is shifting from doing the right thing, to instructing the AI to do the right thing. Even if you're not responsible for the instructing part (e.g. using AI export feature drafts, to use an AI software factory to refine and implement), you're still owning said implementation in the end because you're responsible for the refinement and review. You should know how to do the work and reason about it—but you're also responsible now for correcting AI—less work but more responsibility.
As someone building AI software factories for the greater part of a year, I can share some learnings:
- Smart models like Claude Opus cannot be replaced with dumber models at a reasonable expenditure with similar cost by iterating multiple times. Mythos will be the same cost or more expensive. Don't think you can throw enough funding at qwen-next-coder to rival Opus at a similar price.
- Mythos (like Opus) will change the way we work, but not in the way you think. The use case for Opus is narrowing in comparison to Sonnet - a lot of what Opus used to do, Sonnet can do for cheaper, and sometimes better too. Opus is great at exploring a problem space and filling in the gaps - but any agent harness will not leave such intelligence to fate—they'll do fine-tuning or add specific instructions and possibly guardrails. Lazy (but long-term optimal) solutions will leave more reasoning to smarter models and dictate less.
- A lot of what we do (and should do) is a cost optimization problem. Categorizing what we do (exploration vs. reasoning) tends to be structural (like Haiku), logical (like Sonnet instruct/non-thinking), and reasoning-driven (like Opus/thinking). Sometimes the challenge is long context-based reasoning, e.g. when planning a vision breakdown encompassing 50+ features, Sonnet could* do it given 1M context, but it struggles to reason about long context problems (Opus long-term reasoning drops off less) e.g. first 5 features are accurate, but the further you go, the less accurate it becomes (near-sighted vision).
- If Mythos has like a 10m context size long reasoning window, Mythos would become the go-to model for medium-term planning (3-6 months). Opus 1m doesn't cut it for 3m-6m horizon planning, not to mention long-term (1y+ with 100++ features). The industry is in need of a x10 compression/context size improvement to tackle bigger problems. One of the challenges right now is we (as humans) can't refine and reason about features fast enough to keep pace with what AI can deliver—until AI has the ability to perform longer-term reasoning, we can't trust it to plan things longer term. There's another problem with this long-term reasoning in that we (as humans) can't (easily) reason so far ahead, but AI could if it could keep the entire context in mind.
In short, unless Mythos is cheaper than Sonnet (which is 3-5x more expensive than what is out there today, e.g., GPT Mini, Minimax 2.7, GPT-OSS 120b), it's unlikely it would become the go-to model.
I'd add that a smarter reasoning model can only be better if you provide relevant context and reasoning constraints — otherwise, you can't expect it to behave better (in actual terms) compared to a slightly dumber model. When you start reasoning about the future in terms of AI, it's turtles all the way down (i.e. need AI to efficiently reason about the choices made by AI)
I've always been fond of Rethinkdb, but never actually used it. Perhaps if I came across pragmatic examples of how to do x with y, like you typically see with Redis, I could have convinced my team/s otherwise.
One of the aspects of Rethinkdb I admire most is the tooling. I find myself often trying out something new with React, Postgres, ASP.NET Core, Elm, Go, Kotlin or what not and biasing my experience getting started with preference to use.
I recond Rethink as Pied Piper in Silicon Valley; a great product ultimately being misunderstood. I'm relieved to hear Rethinkdb will live on under the Linux Foundation (and applaud them for doing so) and earnestly hope it re-establishes itself in a niche, such as that of Firebase/Parse, with partnerships and a legacy to rival that of Postgres one day.
Looks to be the case based on the config. I'm suprised storage wasn't abstracted to accommodate redis or the like which is essential in a load balanced scenario.
The API doesn't seem quite idiomatic either, I'd expect to create a struct containing options and a function that closes over the http.Handler interface e.g. func(l *Limiter) Limit(next http.Handler) http.Handler or a function that takes options and a next http.Handler that creates a struct implementing http.Handler.
Edit: The whole idea behind clustering is to run an application instance per thread/core for better performance and load balance requests between the application instances. This article seems absurd in its intention to force you to choose between multi-threaded synchronous application instances or a single application instance using callbacks.
We've been running a Koa.js API server using Cluster in production for over a year now with no hiccups (on a Windows machine).
I've been thinking about making the switch to iisnode, as it handles clustering, graceful shutdown and zero-downtime from within IIS (and does a couple of other things). It uses named pipes to proxy connections and also supports web sockets among other things.
With the nodeProcessCommandLine configuration setting, you can pass parameters to node (e.g. --harmony), use babel-node or io.js.
I guess it depends on how averse you are to risk and how long you can go without getting paid.
Never forget that a contract is meant to be negotiated - a contract's first draft typically contains a bunch of unreasonable or vague requests and wishes from the party that created the contract. Don't sign a contract until the vagueness has been clarified or defined.
It's up to you to negotiate the contract in your favor. To put it plain and simple; unless you negotiate a contract in your favor, you're going to have a bad time. Like the video said; if you have no contract, you're left with the sympathy card and that rarely works.
Another bit of advice: Keep track of all communications and have all word-of-mouth agreements put on paper (before you commit to anything, like signing the contract). I keep a projects folder per client containing communications, documents received etc.
Hourly billing only works when you keep a detailed log of what was done. It's definitely a lot easier to get paid for work if you provide a breakdown on what was decided and done. The descriptions should prove as motivations of why the work was necessary.
- Ask a hefty penalty amount for signing non-disclosure agreements (NDA's) - this is crucial for short term contract work
- Charge more. Figure out your hourly rate and average hours per day and extrapolate that out to a weekly rate. I reckon a fair amount is $50 an hour, while still staying very competitive with other software shops. See: http://internationalfreelancersacademy.com/why-you-should-ch...
- Be honest in what you can and can't do. Advise your client to contract out such work, whether it's designing the look and feel, designing logos or write content. Figure out or develop an advantage over other service offerings. Specialization is of key importance in consulting/freelancing work.
- Beware of overly stingy or difficult clients - it's sometimes necessary to fire them!
It must be IE gathering its numbers to face off against Spartan in the IEpocalypse.
Another theory is that corporates/governments are switching over from XP to Windows 7 (with Internet Explorer 8 as default) because XP was declared "dead" (end of life on April 8, 2014 - no more security updates) and the existing PCs aren't capable of running UEFI required for Windows 8...
Windows 7 and Windows 8 is going to get a free upgrade to Windows 10; it's not far fetched to believe some people are installing a fresh copy of Windows 7 on a clean machine to make use of the free upgrade.
There's definitely a huge difference between supplementing your HTML with some JavaScript and writing a JavaScript application.
JavaScript as a server side language is a new playing field, with different trade-offs, obstacles and design. I built an API service last year using Koajs (alternative to express), Gulp (alternative to grunt) and a bunch of other things.
Recently I've been looking into isomorphic JavaScript single page applications and have been learning a bunch of new things, such as webpack, yahoo isomorphic flux stack (fluxible, routr etc.) and application structuring.
You'll be surprised by how little you really know about JavaScript as a programming language till you start with server side and SPA development.
I'd suggest you start off with building a traditional web application in Node.js (with gulp) before attempting SPA development. Also take a look at React and Babel.
I've setup this fundraiser on behalf of my friend (and donated myself). I know this is not exactly the right place to post this to, if you have recommendations on where to post it will be greatly appreciated
Over the past few years of being a HNer I know that the community can be compassionate, and for this I admire HNer's.
If you can help in anyway it would be greatly appreciated. He's located at Clovis, CA, and in need of shelter, food, some medical supplies and a job. He was employed as a (Network?) Technician at Schneider Electrical and previously Comcast.
Sorry to say, but the design is change intolerant and will most likely fail to meet expectations. Changing the questions or answers will cause all current responses to be invalidated or lost when a question or answer is deleted. The sizes (e.g. varchar(200) for a question) aren't necessarily accurate - what about really long questions or answers?
Typically I'd expect to see:
- Survey (details + configuration)
- Questions (details + configuration; incl. the order)
- Answers (details + configuration)
Survey 1 - * Questions 1 - * Answers
A separate audit table is preferred if you plan to track who changed what and when (ref: "updated" on tables). I'd rather include a "started_at" and "completed_at" on the "survey_response", other metadata like user agent, IP, client time zone etc. would be pretty useful. There's other configuration that's also missing, e.g. from when to when is the survey available? what's the limit of responses? can someone complete the survey twice (or more)?
Overall I'd rate the current design 3/10. It might be good enough for a beginner tutorial, but for production purposes it's not. I'd suggest you go back to the planning phase and review how your design meets your (clients) goals and how realistic it is in terms of usage/ability to change/future needs that can be accommodated now (typically things such as how long it took to complete a survey, or other details - you can't get that data later on if it was never recorded when it was made available).
In the spirit of OSS I forked httprouter instead of just keeping the changes locally. I hope that the implementation can prove as a reference in improving httprouter or other Golang muxers.
I like httprouter, but dislike how the dependency on httprouter.Params pollutes your packages that need to expose httprouter.Handle.
I also dislike the non-standard handler, even with map[string]string parameters. From what I read the proper way to "scope" things in Go is to pass "it" as a parameter to a method; so the dislike is just personal preference. Currently the only way to retain the standard (http.Handler) interface compatibility is to use a synchronized reference map e.g. map[*http.Request]map[string]string, similar to Gorilla Contexts' implementation with only the parameters associated with the request.
Anyway, after all those changes it was a short jump to implement basic middleware helpers and expose an initializer with a standard implementation to associate the parameters with the request.
I hope that answered your questions and thanks for showing interest :) P.S. Check the updated example usage
Learning after school is self-study. Don't expect anyone (even a mentor) to teach you what you need to know.
Every job comes with different challenges and requires learning new things. You'll spend the first few years getting comfortable with the technical side of things. When the business side becomes a more important/bigger challenge than the programming side; that's when you know you're a developer.
My advice is this: identify role models in the fields/technologies you are interested in and follow them. Try to find someone who is more passionate about what you do than you (i.e. someone doing the same things as you but is better than you) and learn all you can.
One of the books I can highly recommend is Evan's Domain Driven Design, it makes it easier to reason abstractly about business.
