HN user
Switzerland, studied at EPFL.
I'm inclined to agree with you, but you could make the same argument for exploiting natural resources and the environment. I don't think it's being done right at the moment, and it does not seem to be benefiting people as much as certain companies.
To be honest, living in Switzerland and speaking with peers, we're just exhausted by the constant AI hype. For a lot of us, the fact that Europe isn't frantically trying to scrape the entire internet and every book in existence for the next massive model isn't a bad thing. The big players are doing their thing, like with the nuclear arms race. We regulate a lot, too much a lot of the time, but sometimes that trickles down to other places too. A lot was done right, imo.
ETH Zurich and EPFL universities recently put out an open model called Apertus (was on the HN front page a few months back), it's not a frontier model, but they built it properly regarding copyright and data transparency.
It might look a bit slow or old-fashioned, but focusing on doing things ethically and legally feels like a much better path than just joining the race to scrape everything.
We need open weights companies now more than ever.
If you're objective it to democratize AI, sure. But for those fed up with it and the devastating effects it's having on students, for example, can opt to actively avoid paying for products with AI (I say this as someone who uses it every day, guilty). At some point large companies will see that they're bleeding money for something that most people don't seem to want, and cancel those $100k/mo deals. I've already experienced one AI-developer-turned company crash and burn.
Personally, I don't think this LLM-based AI generation will have any significant positive impacts. Time, energy (CO2) and money would have been far better spent elsewhere.
Being a moderately frequent user of Opus and having spoken to people who use it actively at work for automation, it's a really expensive model to run, I've heard it burn through a company's weekend's credit allocation before Saturday morning, I think using almost an order of magnitude more tokens is a valid consumer concern!
I have yet to hear anyone say "Opus is really good value for money, a real good economic choice for us". It seems that we're trying to retrofit every possible task with SOTA AI that is still severely lacking in solid reasoning, reliability/dependability, so we throw more money at the problem (cough Opus) in the hopes that it will surpass that barrier of trust.
You could make the same argument for any language. It still requires you to think and implement the solution yourself, just at a certain level of abstraction.
Perhaps I was a little harsh, this was a few years back when I was evaluating Elixir for a client, but ended up going back to a TS/Node.js stack instead. While the Phoenix documentation is stellar, I found it difficult to find good resources on best practices. I was probably doing something stupid and ran into internal and difficult to understand exceptions being raised on the Erlang side, from Cowboy if I recall. In another case, I was trying to validate API JSON input, the advice I got was to use Ecto (which I never really groked) or pattern match and fail. In JS, libraries like Zod and Valibot are a dream to work with.
The result was a lot of frustration, having been thoroughly impressed by Elixir and Phoenix in the past, knowing that I already knew how to achieve the same goal with Node.js with less code and would be able to justify the choice to a client. It didn't quite feel "there" to pick up and deploy, whereas SvelteKit with tRPC felt very enabling at the time and was easily picked up by others. Perhaps I need another project to try it out again and convince me otherwise. Funnily enough, a year later I replaced a problematic Node.js sever with Phoenix + Nerves running on a RPi Zero (ARM), flawless cross-compilation and deployment.
Ports are not network transparent
I stand corrected, thank you for the explanation!
No, they aren't. You have to use BigInt, which will throw an error if you try to serialise it to JSON or combine it with ordinary numbers. If you happen to need to deserialise a 64-bit integer from JSON, which I sadly had to do, you need a custom parser to construct the BigInt from a raw string directly.
This stands to reason. If you need to bridge different languages together like in your case, they need to speak a common tongue. REST/GrahQL/gRPC solve this problem in different ways. There is no technical limitation keeping you from serving HTTP traffic from Erlang/Elixir, but from my own experience it isn't a pleasant experience. JavaScript or Python are dead simple, until you realise that 64-bit integers are not a thing in JS, and need to be handled as strings. Similarly, tuples will give you hell in Python.
On the other hand, if you don't need to cross that boundary, the BEAM will very happily talk to itself and let you send messages between processes without having to even think about serialisation or whether you're even on the same machine. After all, everything is just data with no pointers or cyclic references. That's more that can be said for most other languages, and while Python's pickle is pretty close, you can probably even share Erlang's equivalent of file descriptors across servers (haven't tried, correct me if I'm wrong), which is pretty insane when you think about it.
I have found the real value of Erlang to be internally between trusted nodes of my own physical infrastructure as a high-level distributed "brain" or control plane
I think this is pretty high praise, considering it's about as old as C and was originally designed for real-time telephone switches.
To extend upon this, memory generally has a single owner. When it goes out of scope, it gets freed [1]. The drop() function, which appears analogous to free() in C/C++, is actually just an empty function who's sole purpose is to take ownership and make it go out of scope, which immediately frees the memory [2].
This function is not magic; it is literally defined as: pub fn drop<T>(_x: T) {}
This is usually more deterministic than GC languages (no random pauses), but can be less efficient for highly nested data structures. It also makes linked lists impossible without using "unsafe rust", as it doesn't abide by the normal ownership rules.
[1] https://doc.rust-lang.org/rust-by-example/scope/raii.html [2]: https://doc.rust-lang.org/std/mem/fn.drop.html
Never heard of shadcn or franken-ui, but they look identical, one links to X (Twitter), the other to Mastodon. What's the story there?
This is clean JavaScript syntax in my opinion and should be what people strive for. It's perfectly readable, it's faster, it does async correctly without any unnecessary computation, can be typed and will have a normal stack trace. Piping is cool when done right, but can introduce complexity fast. Elixir is a good example where it works wonderfully.
The two are not mutually exclusive, it's probably not an issue with horizontal scaling.
I think this is a great use case. From my experience, having everything in one language is a huge plus. You can pull data from the database and just inject it into the view. The closest I've gotten to this in the JS/TS world is a Prisma + tRPC + SvelteKit for E2E type safety, but there's a huge cost in complexity and language server performance and some extra boilerplate.
The main limitation is likely offline apps, LiveView requires a persistent connect to the server. I doubt this is something you'll encounter for your use case.
I decided to use Tauri for the first time for a university project and it was absolutely painless to design a small and useful GUI application to programatically generate schematics for photolithography masks.
- Single lightweight binary install and executable (~6 MB), clean uninstall
- Automatic updates (digitally signed, uploaded to a small VM)
- Integrates nicely with SvelteKit and TailwindCSS
- The Rust backend was able to integrate with GTSDK over FFI. The cmake crate made C++ compilation and linking automatic as part of cargo build, provided that a C++ toolchain is available (no problems even on Windows).
- No scary toolchain setup with a load of licenses to review and accept (looking at you, Flutter. I'm a student, not a lawyer. Although perhaps this will also be a thing with Tauri + Android?)
For a small project, I can't recommend it enough. I wouldn't know where to start with a C# or Qt GUI application, especially if I wanted to make it cross-platform.
It'll be interesting to see if it gains any traction in the mobile space. Flutter is great and may be better optimised for certain rendering techniques, such as infinite lists, but sticking with web technologies is a very compelling advantage.
I guess this comes down to personal preference. For me, this is mixing the interface with the implementation. You shouldn't need to know how something works to be able to use it, for me, that's the real overhead. Maybe this works on a small scale, but what if the source code changes?
That being said, I do like inspecting the source from time to understand it better, or make up for missing documentation. Sometimes though, with this being JS, I wish that I could unsee the things that I've seen, code that production depends upon, deep within the dependency tree.
I agree with the idea of fluency when writing without types, but for me it's not about how fast you can write code. Code for me is a lot of rereading and understanding what the hell you wrote just a few days ago, I find typed code easier to get back into and it's faster to find things that broke in parts of the codebase that you're less familiar with when you change something.
Just for fun, I tried the static variable approach for myself. I have to agree with you, it's really hard. I gave up after half an hour. Rust doesn't seem to like casting references to pointers, which I understand, as I don't think there's a guarantee that they are just pointers. A &T[], for example, is a fat pointer (two words, also encodes the count). I think the correct approach here is either accept runtime overhead, or pass a context to each function as a parameter.
I also agree with your other statement. I think Rust tries to abstract a lot of behind into its own type system, such as Box<T> for pointers, whilst keeping it relatively fast. C is definitely the right tool for the job if you want direct memory access, I also think this is a relatively small proportion of people, working on OS, embedded systems or mission critical systems such as flight control/medical equipment.
I don't want to come off dogmatically defending Rust, I code little Rust in comparison to JS, and I've done C and C++ for some embedded systems. C is a very different monster to most other languages, I find people defending C to be just as proud and defensive as Rust programmers.
To address some of your complaints: yes, there are a lot of concepts to understand. I like wrappers, I found it crazy that in C, you first declare a mutex_t variable, and then you specifically have to call chMtxObjectInit(*mutex_t mutex) to initialise it [1]. If you forget? UB, kernel panic sometime in the future. I think Mutex::new() is far cleaner, and it's namespaced without arbitrary function prefixes. Binaries are tiny in comparison to JS/Python with deps, they will be larger than C. Compile times aren't that slow and you can't make extra language features happen out of thin air.
In C, I've found that it's commonplace to do a lot of clever and mysterious pointer and memory tricks to squeeze out performance and low resource utilisation. In embedded, there's usually a strong inclination to using "global" static variables, even declaring them inside function bodies because it "limits the visibility/scope of the variable". Not declaring a static variable inside a function is what knocked a few points off my Bachelor's robotics project.
I personally don't like this. It puts a lot of pressure on the programmer to understand the order of execution, and keep a complex mental model of how the program works. Large memory allocation, such as a cache, can be hidden in just about any function, not just at the top of a file where global variables are usually defined.
It sounds like what you're trying to accomplish is inherently unsafe, hence the "preaching", as in it requires the programmer's guarantee that 1) the data is fully initialised before it's accessed and 2) once the data is initialised, it's read-only and can therefore safely be accessed from other threads. C doesn't care, it will let you do a direct pointer access to a static variable with no overhead. Where's the cost? The programmer's mental model. I haven't tried, but I imagine that Rust's unsafe block will allow you to access static variables, just like in C with no overhead, effectively giving your OK to the compiler that you can vouch for the memory safety.
Rust solutions: lazy_static crate (safe, runtime cost in checking if initialised on every access), RwLock<Option<T>> (safe, runtime cost to lock and unwrap the option), unsafe (no overhead, memory model cost and potentially harder debugging), extra &T function parameter (code complexity cost, "prop-drilling", cleaner imo). On modern hardware, the runtime cost is absolutely negligeable.
Why would you not want to use Rust for a large project? This seems a bit contradictory to me. The safety guarantees in my opinion really pay off when the codebase is large, and it's difficult to construct that memory model, especially with a team working on different parts. Instead, you overload that work to the compiler to check the soundness of your memory access in the entire codebase.
If you like C, by all means keep on using it, I enjoyed my forray into C, it's simple and satisfying, but would much prefer Rust, after spending a lot of time tracking down memory corruption. Rust's original design purpose was to reduce memory bugs in large-scale projects, not to replace C/C++ for the fun of it. We usually have a natural inclination to what we know well and have used for a long time. Feel free to correct me if something is wrong.
1: http://www.chibios.org/dokuwiki/doku.php?id=chibios:document...
This kind of already exists in the form of #[no_panic] [1]?
If the function does panic (or the compiler fails to prove that the function cannot panic), the program fails to compile with a linker error that identifies the function name.
Really hard question to answer simply. They're two languages that are at very opposite ends of the spectrum, yet they can usually both accomplish the same goal. I think the main difference is that Rust is significantly faster and uses less memory in the majority of cases, but also harder to learn and to reason about. Good package manager, tooling, etc, is a nice to have.
Python focuses on being simple, interpreted and dynamicaly typed, Rust requires you to specify the exact types of all the things (like C/C++) which allows it to generate really optimal compiled machine code before execution, it has more information to work with. Accessing a struct/"object" field is not a hash table lookup, it's a direct pointer access, as the exact size of things are known at compilation time.
If you're writing a script, a tool, a small game, it's simpler to use Python. If you're writing a database engine, a mission-critical piece of code that has to behave predictably without the possibility of random GC pauses, anything that has realtime constraints such as audio, lower-level languages like C, C++ and Rust are a must.
A lot of higher-level folk seem to enjoy Rust as well, especially in networking/the web, for whom the speed is worth the additional difficulty and complexity.
This is by choice, while it is really convienient to interrupt execution flow by throwing an arbitrary value, it's extremely hard to know whether calling library code can throw, and if yes, what kind of errors, without exceptional documentation.
The Result<T,E> type is very explicit, and can be easily ignored, composed or "re-thrown" with the "?" suffix without nested try/catch blocks. Return value based error handling is something Go, Elixir and other more functional languages have also adopted.
Panic is there to aleviate the really exceptional circumstances, when the trade-off for possible program termination is worth the much simplified error handling, such as when casting to a smaller integer type in case of overflow, or locking a mutex when it may be in a posioned state (which, funnily enough, can arrive when a panic occurred whilst the mutex was previously locked, i.e. the mutex guard is dropped during a panic).
Probably more to do with the fact that people are mashing F5 to see the difference.
I've been using WSL, which you can get from the Store now. Works for development and building releases, which then deploy to an Ubuntu VPS.
From the repository that I found, it seems that you wrote the backend in Go. How did it hold up? Any lessons learned?
I've done some C/C++, a lot of JS/TS due to its web dominance. I found Elixir a year ago and fell in love with it.
I love the functional style of Elixir, it's elegant to write and read, but feels unsafe. The lack of a type system is hard for me and has been a nightmare when trying to find the origin of a particular error tuple and refactoring code, running the app to see if it works. Running it in production feels like a ticking time bomb, even if it does handle fault tolerance gracefully.
I've reached for Rust for the occasional project and have never regretted it, I couldn't justify its use for everything though. Very high-quality ecosystem, rock solid and predictable performance and tiny footprint. I've made a VPN supervisor process that fits in a few MB Docker image (without OS), uses a few MB of RAM, no idle CPU and wonderful latency.
Perhaps Erlang can manage tail latencies better under load, pre-emptive scheduling is awesome, but my personal experience has been that Rust is just much more efficient at doing the same task, giving you more free CPU time, predictable memory freeing that rivals Erlang's per-process GC. You finish that blocking computation before it even becomes noticeable. Erlang’s fault tolerance is matched by Rust’s type system and memory safety guarantees. It's hard to compare C++/Rust to Erlang/Python/Ruby, they're just different.
It's slower and more frustrating to write, but the language server gives you so much feedback and useful comments. I find the linter amazing, it finds some pretty obscure and neat improvements with the additional type information it has, and Option<T> and Result<T,E> have an almost functional-like chaining pattern.
For a small hobby project, Rust 100% of the time. No painful dependency management, no complex build process. For a more serious project, or for a client, not always justifiable. I always miss Rust’s language features and libraries when coding in another language that has the upper hand in their respective dominant fields, although I like that a lot of tooling (ESBuild, swc, Tailwind's compiler, fnm, Rome, ...) is being remade in Go/Rust, it benefits far more people than it inconveniences.
This is brilliant. Just made my day
That's perfectly sufficient for a large number of use cases, keeping things simple.
The edge isn't just where the cool kids hang out, through. There is a very noticable latency hit over long distances, amplified by the number of round trips needed. If you have a local business, this isn't a problem.
Making it super simple to deploy things to the edge, and developing systems to make it easier to push data that can be cached to the edge to avoid trips to a central database, is awesome even for hobbist programmers, like Heroku made it easy to deploy applications without worrying about VMs.
The type inferrence only applies to ReScript code, it's not a magic compiler that can statically analyse JS code and generate interfaces for any arbitrary npm package. For Typescript interop, it can "trust" the TS declaration files, but there is no real guarantee when you're crossing language boundaries. ReScript is it's own language, with it's own type system that compiles down to JS. I don't think there's a reasonable alternative to this.
Take Rust, calls to C code are inherently unsafe, and must be marked as so. You're leaving Rust's source code and type system and calling into external functions that you may not even have access to source code for and that the compiler just can't feasibly vouch for.
I don't understand why ReScript is trying to sell itself as a language for React. React is already "kind of" functional, has a rich JS/TS ecosystem and there are fantastic alternatives such as Elm.
I think this would have huge potential in the backend space if it had good interop with Node.js and TS, with perhaps a functional framework similar to Elixir's Phoenix. Elixir proved it can have fantastic integration with Erlang.
* More robust applications with the Result type
* An actual integer type (for 64-bit database keys, Prisma uses BigInt)
* Finite state machines for stateful logic, games, websockets (enums and a sound type system)
* Benefit from the JS-centric serverless ecosystem
We've already been "compiling" or "transpiling" JS for years, most of written JS code has little in common with what is actually run.
In its current state, I don't even want to imagine what it would be like to set this up alongside ESM, TS, Prettier, ESLint, Jest, Storybook, ESBuild, Vite, (insert cool tool here). I've already spent literal days trying to setup a "modern" Node.js project, only to give up and go back to CJS for simplicity and import older non-ESM versions of packages[1], wish I wasn't using Node.js, then remember how many things I miss from JS when trialing another language.
It takes time to establish discoverability with a website, you either rely on a search engine, word of mouth, business cards, etc. A new small-business website won't magically start generating traffic without some significant effort.
Using a platform like Facebook or Google Maps makes it easier to for other people to find your page when they want to look for it.
I'm not an expert, but here's my take.
The public key is generally not considered a secret and is therefore "less guarded". Anybody with access to the public key is able to encrypt and create legitimate looking files that are indistinguishable from the original files. You can still only decrypt them using the private key, but you can no longer trust the contents of the file as your own.
A solution would be to encrypt with the public key, and then _also_ sign with the private key. When reading, you work in reverse order. You verify the signature using the public key, and then decrypt the file using the private key.
But then if you're just using both, why not use fast and robust symmetric encryption instead? Not only will decryption be garbage if the file has been tampered with, but you can also create a signature to detect it (HMAC).