Most of my code in the last year and a half has been Odin. My personal codebase moved from C11 to Odin. I would say that Odin is just more streamlined and easier for a beginner to learn with (which is who Raylib is aimed at.) Both syntax and semantics are simpler; so much so that the (relative to C) smaller ecosystem doesn't pose a problem to learners.
I like Odin because it values the low-friction of C, unlike just about every other "better C" I've tried. It adds friction where you're likely to cut yourself, and reduces friction where it matters; in places like:
- having semantic modules instead of textual inclusion
I think the magic is still mostly in raylib in that it's a well designed API with high composability. It feels like playing and building. Odin is special in its own right.
There's no particular feature of Odin that really stands out, but where Odin outclasses every language available is that every single feature has been very thoughtfully considered and designed to have the least amount of issues. Once you work with it for a few months, it becomes obvious very quickly its vision is remarkably consistent, leading to a smooth and outright delightful development experience.
I will caution, if you are the type of developer who likes to pull in lots of packages and dependencies to start a project, it's not for you. There's no package manager, and rightly so[1]. You'll have to build most high-level systems yourself. But when you realise that most frameworks and dependencies are trivial to implement by hand, this won't be a bother.
If you're the kind of developer who loves building systems and doing everything yourself, you'll feel right at home.
(Did not read the article, can’t speak to the exact argument the OP made)
I like this argument in the sense that JavaScript & HTML were/are awesome because you can learn from websites that you like the look of. You can just pop open inspect and directly see how to do something.
Modern frameworks have largely broken this to the point that it’s pretty difficult to understand what’s going on on a lot of pages
Yes, but it's not the fault of these frameworks.
If people wanted to they could ship source maps on purpose and not just accidentally.
Not exposing source code was one of the early drivers for tooling.
Seems a bit strange to posit fault tolerance as an alternative to a type system. Personally, I view type systems as a bonus to DX more than something strictly designed to prevent errors
It's in line with the erlang philosophy of letting things crash trivially and restart instantly. Due to the universal immutability, starting a new process from a given state in Erlang/Elixir is nearly instantaneous and has extremely little overhead as they are not OS threads, they are BEAM VM threads.
LOL. This only makes sense if you can know all the ways your code will fail... which you cannot.
Erlang/Elixir's approach is to simply say, "It's gonna fail no matter how many precautions we take, so let's optimize for recovery."
Turns out, this works fantastically in both cellphone signaling, which is where OTP originated, as well as with webserving, where it is perfectly suited.
whether that matters or not depends on whether the logic error occurs because of a rare combination of events or as a result of a certain state and whether that state remains after recovery. if there is for example a logic error that causes the app to crash after say 10 minutes of runtime, or eg. at a certain message size, then a recovery will reset the runtime and it will work again. it will of course invariably fail again after another 10 minutes or when the same message is resent, because it is a logic error, and logic dictates that the error won't go away no matter how often you restart, but it will work in the meantime.
in other words, any error that doesn't occur right at start can be recovered from at least for all those operations that do not depend on that error being fixed.
This sound like a wild and very contrived argument.
Both because that memory leaks are normal is types languages - and does usually not matter in most serious applications - and because this class of errors is usually not what types catch.
Types have value when you 1) refactor and 2) have multiple people working on a code base.
The error you see when you don't have types is something like a BadArityError.
It doesn't prevent the error, but it also won't take down your server when malicious users (or just lots of normal users) start to bang on that input with the problem, and your non-BEAM VM pool starts to run out of available preloaded stacks... You get a new Erlang process in well under a millisecond on modern hardware
It WILL log the error, with a stacktrace, so you have that going for you
Note that even with typing, you cannot avoid all runtime errors
Also note that this tech was first battle-tested on cellphone networks, which are stellar on the reliability front
Without more details on their exact use case, their algorithms, and their data movement patterns, you have no way of knowing this. Doing stuff on the GPU isn't automatically faster than doing it on the CPU.
I recall seeing some discussion about the UI density Japanese websites (specifically Japanese news sites). For example: https://www.asahi.com/
Now that I think about it, news sites in general have fairly high density UIs, not that I consider them to be shining examples of great UIs.
https://www.yahoo.comhttps://www.bloomberg.com/
Regarding Bloomberg, the Bloomberg Terminal is also a good example of a really information dense interface. There is a few videos on YouTube where Bloomberg shows examples of how to use their terminals.
Yes, exactly. It probably makes more sense if you understand the terms used in the financial industry. Overall I'm just fascinated by the whole system, everything from the design language, the UI, the infrastructure and the keyboard.
https://kakaku.com (A shopping comparison and review site) has menus not as long as McMaster-Car (down the left side), then more menus in the body and tabs thrown in to boot when you reach a product. Each product page is jam packed with more information. A lot of information yes, good design, not so sure.
Correct, we're a lean team that moves very quickly, so availability for synchronous communication is important to us.
That said, the expectation is not that you're sitting idly at your computer for an extra 15 minutes at the end of the day if you've knocked out your work and are at a good stopping point. We hire adults and treat them as such :)
Also, many folks on the team have familial and other responsibilities that they need to tackle during this window, and the team is very flexible about scheduling around these (especially given advance notice when possible).
reply