Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I like Odin

hasenjudy.wordpress.com

Post reply on HN
Print view View original

181–190 of 211 posts

Re: I like Odin

#181

Post by agumonkey »

rgoulter wrote: post #32
agumonkey wrote: post #9

Earlier quoted context omitted.

I always interpreted go "system" as networked async systems and not electronic chip systems.

I think this makes sense considering that most of the cloud-native software is written with Go. (Docker / Podman, Kubernetes, Helm, Istio, Terraform, etc.)

I don't know if I'm crazy but it matches the definition of a system. Coupling different parts together. These are just high level systems, and unsurprisingly when people see 'system programming language' they want to see high level assembly like C; but it's misplaced reflex in this case.

Re: I like Odin

#182

Post by sanderjd »

hsn915 wrote: post #172
sanderjd wrote: post #46

Earlier quoted context omitted.

Yeah this kind of framing always rubs me the wrong way. I don't "dread" manual memory management. Indeed, from a personal standpoint I really like thinking about stuff like that while I'm programming. It's part of the fun puzzle aspect that got me into all this. But as a professional , I know that there is heaps of evidence over many decades that it is unwise for me to indulge this fancy, when working on real systems…

If you had this belief say, 10 years ago, and because of it you decided to write your serious application in say, Java, you would have been in for a huge unexpected surprise last year when the now infamous log4j vulnerability was made public. See, having memory safety did not prevent the language from causing arbitrary code execution vulnerabilities. Having the log4j project be open source and popular did not prevent…

Highlighting a different systemic problem is not at all an argument against avoiding this problem. Indeed, if memory safety were the only problem to worry about, then I'd be less worried about it, because we could spend more time on it. But it isn't, there are all sorts of other things to worry about, simultaneously.

> This would be like judging SQL statements as fundamentally unsafe because websites written in PHP tended to (specially in the early 2000) be written in a very unsafe manner where user input was put directly into SQL strings.

This is indeed a good example, but supports my argument rather than yours. If we had devised ways to make it impossible (or incredibly hard and weird) to introduce sql injection vulnerabilities at the language level, then that would be excellent. One less thing to worry about!

I don't have a unique grudge against memory safety issues. It's just one type of issue that we've spent a lot of time devising solutions to that don't just boil down to "be very careful" and I'm generally supportive of any solution to any problem like that, if the tradeoffs are acceptable.

But I agree with you that it's a great thing to have language and library support that make memory safety issues significantly less common and problematic (to be clear, I only just heard of Odin from this article, but I think it looks pretty awesome on initial glance), and that that gets to the level of solution that we have for sql injection in practice. I think there are somewhat better alternative solutions available in the case of memory safety, but they have different tradeoffs.

> What remains is a matter of what attracts you to programming: are you interested in having explicit control over a system to make it do what you want, or are you more interested in expressing some abstract ideas in an abstract mathematical virtual machine?

I'm mostly interested in the first thing, but I think these are both false choices. There is a language that provides that explicit control with more memory safety (rust) with a different trade off (language complexity), and most other languages are memory safe without being focused on expressing abstract ideas in an abstract mathematical virtual machine (go, java, python, etc. etc.).

Re: I like Odin

#183

Post by baq »

jcelerier wrote: post #179
baq wrote: post #178

Earlier quoted context omitted.

That’s basically any gced language and the fix is present for decades at this point: try-with-resources, ‘using’, ‘with’ (with-whatever IIRC can be traced back to Lisp…)

no, those are absolutely not fixes: you have to remember to use "using", "with", etc. whereas you have to go out of your way to circumvent RAII

Non-issue. You can use fopen in C++ and remember to fclose, too.

Re: I like Odin

#184

Post by B1FF_PSUVM »

gautamcgoel wrote: post #155
B1FF_PSUVM wrote: post #100

Drats, not the Norse deity. In case you're also disappointed, I recommend Votan by John James https://books.google.com/books/about/Votan.html?id=y-OlAwAAQ... """ In the second century AD, a Greek nobleman is travelling and living abroad in Germany while carrying on an affair with a military man's wife. When discovered, he takes an emergency business trip to save his life and packs amongst his belongings certain items…

Sounds like The Road to El Dorado :)

It's that sort of tale, the picaresque adventures of a likeable scoundrel (or two). The John James tale checks most features of the Odin story with explainable real-world incidents.

He wrote a couple of sequels that go on to Irish mythos, etc.

Re: I like Odin

#185

Post by Kukumber »

dxuh wrote: post #159
Kukumber wrote: post #122

Earlier quoted context omitted.

How do you write your garbage collectors or RC without precise manual memory management? How do you render billions of vertices and maintain a gameplay loop under 8ms for AAA games without precise manual memory/layout management? Not everyone is writing websites in javascript

RAII is often optional automatic memory management, like in C++ or Rust. Both of these languages are used for AAA games and rarely used for websites. My point was that if you don't go as far as those two, there is just not much of a point to not using C instead.

Rust is not used in the AAA industry, it was advertised by a company (Embark), but they ended up using Unreal Engine 5 for both of their new upcoming games

Re: I like Odin

#186

Post by dxuh »

davedx wrote: post #175
dxuh wrote: post #161

Earlier quoted context omitted.

My point was that I don't see much of a point in yet another language that is C with an extra 10%. There is another one like that almost every week. Plenty of applications that require manual memory management have been written in C++ or Rust, which do provide RAII. If you know that manual memory management is required for some applications, you also know it's not 100% of the code that needs it.

Quoted post unavailable.

You're right. I'm sorry. It got too heated below my initial comment and I got upset. I'm not in a good place currently and I should probably refrain from commenting at all. And yes, I am not fun at parties.

Re: I like Odin

#187

Post by godratio »

dxuh wrote: post #165
gingerBill wrote: post #121

Earlier quoted context omitted.

Still no. Many problems require manual memory management of which custom allocators aid a lot with. Odin has extensive support for custom allocators and many other things. RAII may not even make sense within the type system of a language too. Languages with RAII (C++, D, Ada, Rust (through Drop), and Vala) all have higher level constructs such as methods, and many have automatic memory management too (Rust's is autom…

I want to address some points for people that are reading and don't have enough C++ experience to judge that they are not as serious as they might seem. * You can just have your constructors not initialize your member variables. If they don't have default constructors that do work, then no work is done. * Yes, originally. Move-semantics are part of the language since C++11. Enough time has passed. * I read and write…

The value is having an alternative closer to C and farther away from the garbage lang that C++ has become.

No one is expecting you to rewrite your entire project in Odin but those that are starting new projects have a high value choice with Odin and others.

Re: I like Odin

#188

Post by godratio »

dxuh wrote: post #159
Kukumber wrote: post #122

Earlier quoted context omitted.

How do you write your garbage collectors or RC without precise manual memory management? How do you render billions of vertices and maintain a gameplay loop under 8ms for AAA games without precise manual memory/layout management? Not everyone is writing websites in javascript

RAII is often optional automatic memory management, like in C++ or Rust. Both of these languages are used for AAA games and rarely used for websites. My point was that if you don't go as far as those two, there is just not much of a point to not using C instead.

NOT TRUE you would of course choose Odin over C unless you could not for some reason.

Odin is 100x better environment to program in than C. C++ is used for AAA games. Rust is not really used if hardly at all because of the highly competitive and time critical nature and very much the need to change things fast.

Re: I like Odin

#189

Post by debug-desperado »

"I like Odin" - me too, just discovered Odin last week. The syntax is just about as perfect as a procedural language can get.

I don't do C professionally and really only used for standard uni classes for algos, data structures, system programming, OS, etc. But seeing Bill's streams highlighting the clarity of the Pascal pointer syntax has been eye opening. A C spiral seems so utterly unnecessary compared to how simple it is to read Odin left-to-right. It's good to have a physicist take on a programming language. Thanks for the hard work!

Re: I like Odin

#190

Post by jcelerier »

baq wrote: post #183
jcelerier wrote: post #179

Earlier quoted context omitted.

no, those are absolutely not fixes: you have to remember to use "using", "with", etc. whereas you have to go out of your way to circumvent RAII

Non-issue. You can use fopen in C++ and remember to fclose, too.

No, every time you have something that sound like "you just have to [...]" it means future bugs that were entirely preventable. The only correct way in c++ is to wrap it in a unique_ptr or handle type so that fclose gets called automatically when you are done with the resource
Post reply on HN