5 ms·

Whenever I see a language like this (niche and new yet more than a toy, minimal ecosystem/tooling support, and evolutionary - not revolutionary - improvements o

by _bxg1 7y ago

Whenever I see a language like this (niche and new yet more than a toy, minimal ecosystem/tooling support, and evolutionary - not revolutionary - improvements over a much more widely-used language), I have to wonder, who's actually using these languages, and in what contexts? Where does the build complexity/hiring difficulty/lack of tooling tradeoff make sense for the advantages that one of these languages offers in return? I'm genuinely asking; any anecdotes out there?

brakmic 7y ago
These days programming languages are going the way of JavaScript frameworks.
gingerBill 7y ago
One of the big users of Odin at the moment is JangaFX's EmberGen, which does real-time volumetric fluid simulations for games and film. https://jangafx.com/software/embergen/ https://jangafx.com/software/embergen/ Odin has aided them with a huge amount of productivity and sanity of life which other languages such as C or C++ cannot offer, such as a strong and comprehensive type system, parametric polymorphism which is a pleasure to use, the implicit context system, extensive support for custom allocators, the `using` statement, the `defer` statement, and much much more.
- deadEndDave 7y ago
  > which does real-time volumetric fluid simulations for games and film With all of the advantages you listed, what do you think the possibility of Odin becoming more widely accepted in other fields who could benefit from using it?
- keldaris 7y ago
  Given the extent to which real-time fluid simulation consists of GPU computation, is there anything that makes Odin particularly suited to that domain apart from the basic requirement of control over memory allocation and alignment? I'm more on the scientific side of CFD (so CUDA more so than shaders), but always interested in improving upon the kind of orthodox C++ I usually write.
  - tudelo 7y ago
    is 'orthodox c++' a thing? i feel like there is a joke somewhere there...
    - keldaris 7y ago
      It's a reference to [1] and a mindset arguably most common in the gamedev world that emphasizes simplicity, pragmatism and performance (including compile time performance) over many aspects of "modern C++". I've found it useful and productive, YMMV. [1] https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b
      - ttctciyf 7y ago
        That's an interesting (and I think worthwhile) read! Just how much it upset the denizens of r/cpp[1] is a sight to behold: > This starts ridiculously, then it gets worse ... > looks like a solid way to produce abysmal quality code ... > just learn the fucking language like everybody else ... > The trolls from r/javascript are brigading us again It seems 1: https://www.reddit.com/r/cpp/comments/41b3o3/orthodox_c/ https://www.reddit.com/r/cpp/comments/41b3o3/orthodox_c/
  - dotbmp 7y ago
    Odin doesn't have CUDA-like GPU interoperability, so the benefits are going to be purely client-side. If you were working in say OpenCL + C the benefits are more obvious, with CUDA you're not going to get an analogous experience. I would say in my experience that Odin is definitely preferable as a client language for the simple reason that it's a nicer systems programming environment than other languages, but it's not (at least right now, future developments could always change this) equipped to run native GPU code. Things like SPIR-V and "shader ASM" open up some interesting possibilities once the custom backend is implemented, but the complexity of integrating GPU execution means making it a first-class feature it probably unlikely.
  - Vassvik 7y ago
    As most of the heavy lifting in Embergen is done on the GPU via shading languages the main benefit in using Odin isn't necessarily anything to do with memory control compared to the usefulness of its remaining feature set. The simplicity of the language and its ergonomic set of features does a good job at reducing friction and it is a joy to program in. Simply not being bogged down in all the complexities of C++ in all their forms, nor being held back by the arcane annoyances of C is quite refreshing.
Touche 7y ago
I think you are operating from the bias of big programming departments where hiring for a specific language is a thing. Some companies don't assume that you need to know their specific stack before hiring. And some programmers program outside of a work setting and hirability isn't part of their decision making.
- _bxg1 7y ago
  I do lots of programming outside of a work setting and I still appreciate good library and tooling support. And even if the programmers at a company are expected to be able to jump around, combining multiple languages makes building and interop more complicated.
  - Touche 7y ago
    I can't speak for Odin but Zig (also a niche language) is compatible with all C libraries so the ecosystem side is very good.
    - _bxg1 7y ago
      That makes sense. I guess I assumed the interop story would necessarily be arduous and crufty, but if both languages are native I can see how you might get more of it "for free".
      - dotbmp 7y ago
        Odin requires writing bindings (for the moment, this will likely be automated with third-party tooling), Zig actually has full first-class C importation. In both cases the interoperability is excellent imo. I can't speak to Zig as much, but Odin's type system makes working with C APIs much more of a pleasure than doing so in C itself.
lang_throw_away 7y ago
throwaway because I don't want to DOX myself I'm working with language development where we're deploying a custom language built with another custom language. >who's actually using these languages, and in what contexts? Compare it to using C in 1970 or Ruby in 1995. It's people who have a real problem they're trying to solve for which existing tooling and widely used languages are a poor fit - as well as people who genuinely enjoy developing their own PLs that have their own ways of doing things. >Where does the build complexity/hiring difficulty/lack of tooling tradeoff make sense With VC money, anything is possible... >build complexity Fairly nil. Contemporary build systems are language agnostic, and the steps to make one that functions good enough are well known and can be thrown together in a week or so. Not to mention it's become increasingly common for "widely used" PLs to fallback on things like python scripts to handle builds. >hiring difficulty It's actually a fantastic way to weed people out and find good candidates. In my (limited) experience, people willing and able to learn a new language (or have a few under their belt) are generally the exact kinds of people you want to hire anyway. Code switching between languages on a daily basis is a fantastic skill, and leads to good developers and mindshare, helps create a diverse technical background. >lack of tooling This is a legit problem, and one that a lot of folks stumble on. But luckily building tooling is a great way to dogfood your language - and it's never been easier to integrate with various tool frameworks via standard protocols. But that said - every company just getting off the ground lacks tooling. For language devs it's a language server, debugger, disassembler, and what have you. For your bootstrapped startup it's build systems/procedures and code review, ERPs and CRMs, etc. Building your own tooling is a part of the growth of a business, tech or otherwise, it's just that when you work on a custom language you have to build some different tools than a SaaS might. I'll throw one more in though that's the biggest hurdle - wheel reinvention. Stuff you take for granted in any language or have great packages for are the biggest blockers to being productive. But you do the ROI math and decide if it makes sense, so hopefully your lang has good FFI. Also worth mentioning - if you're working in an esoteric language with heavy contribution by your own team, you're probably doing it because you have a lot of work that looks nothing like putting together a CRUD app or developing a backend for your latest API for your SaaS idea.
- gingerBill 7y ago
  Odin's `foreign` system (FFI) is very easy to use and allows for a lot simpler build system in the process too. I highly recommend you read the overview (https://odin-lang.org/docs/overview/ https://odin-lang.org/docs/overview/) and many of the Odin wrappers and bindings for more information on this topic https://github.com/odin-lang/odin-libs https://github.com/odin-lang/odin-libs

by _bxg1 7y ago

brakmic 7y ago

These days programming languages are going the way of JavaScript frameworks.

gingerBill 7y ago

One of the big users of Odin at the moment is JangaFX's EmberGen, which does real-time volumetric fluid simulations for games and film. https://jangafx.com/software/embergen/ https://jangafx.com/software/embergen/ Odin has aided them with a huge amount of productivity and sanity of life which other languages such as C or C++ cannot offer, such as a strong and comprehensive type system, parametric polymorphism which is a pleasure to use, the implicit context system, extensive support for custom allocators, the `using` statement, the `defer` statement, and much much more.

deadEndDave 7y ago
> which does real-time volumetric fluid simulations for games and film With all of the advantages you listed, what do you think the possibility of Odin becoming more widely accepted in other fields who could benefit from using it?
keldaris 7y ago
Given the extent to which real-time fluid simulation consists of GPU computation, is there anything that makes Odin particularly suited to that domain apart from the basic requirement of control over memory allocation and alignment? I'm more on the scientific side of CFD (so CUDA more so than shaders), but always interested in improving upon the kind of orthodox C++ I usually write.
- tudelo 7y ago
  is 'orthodox c++' a thing? i feel like there is a joke somewhere there...
  - keldaris 7y ago
    It's a reference to [1] and a mindset arguably most common in the gamedev world that emphasizes simplicity, pragmatism and performance (including compile time performance) over many aspects of "modern C++". I've found it useful and productive, YMMV. [1] https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b
    - ttctciyf 7y ago
      That's an interesting (and I think worthwhile) read! Just how much it upset the denizens of r/cpp[1] is a sight to behold: > This starts ridiculously, then it gets worse ... > looks like a solid way to produce abysmal quality code ... > just learn the fucking language like everybody else ... > The trolls from r/javascript are brigading us again It seems 1: https://www.reddit.com/r/cpp/comments/41b3o3/orthodox_c/ https://www.reddit.com/r/cpp/comments/41b3o3/orthodox_c/
- dotbmp 7y ago
  Odin doesn't have CUDA-like GPU interoperability, so the benefits are going to be purely client-side. If you were working in say OpenCL + C the benefits are more obvious, with CUDA you're not going to get an analogous experience. I would say in my experience that Odin is definitely preferable as a client language for the simple reason that it's a nicer systems programming environment than other languages, but it's not (at least right now, future developments could always change this) equipped to run native GPU code. Things like SPIR-V and "shader ASM" open up some interesting possibilities once the custom backend is implemented, but the complexity of integrating GPU execution means making it a first-class feature it probably unlikely.
- Vassvik 7y ago
  As most of the heavy lifting in Embergen is done on the GPU via shading languages the main benefit in using Odin isn't necessarily anything to do with memory control compared to the usefulness of its remaining feature set. The simplicity of the language and its ergonomic set of features does a good job at reducing friction and it is a joy to program in. Simply not being bogged down in all the complexities of C++ in all their forms, nor being held back by the arcane annoyances of C is quite refreshing.

Touche 7y ago

I think you are operating from the bias of big programming departments where hiring for a specific language is a thing. Some companies don't assume that you need to know their specific stack before hiring. And some programmers program outside of a work setting and hirability isn't part of their decision making.

_bxg1 7y ago
I do lots of programming outside of a work setting and I still appreciate good library and tooling support. And even if the programmers at a company are expected to be able to jump around, combining multiple languages makes building and interop more complicated.
- Touche 7y ago
  I can't speak for Odin but Zig (also a niche language) is compatible with all C libraries so the ecosystem side is very good.
  - _bxg1 7y ago
    That makes sense. I guess I assumed the interop story would necessarily be arduous and crufty, but if both languages are native I can see how you might get more of it "for free".
    - dotbmp 7y ago
      Odin requires writing bindings (for the moment, this will likely be automated with third-party tooling), Zig actually has full first-class C importation. In both cases the interoperability is excellent imo. I can't speak to Zig as much, but Odin's type system makes working with C APIs much more of a pleasure than doing so in C itself.

lang_throw_away 7y ago

throwaway because I don't want to DOX myself I'm working with language development where we're deploying a custom language built with another custom language. >who's actually using these languages, and in what contexts? Compare it to using C in 1970 or Ruby in 1995. It's people who have a real problem they're trying to solve for which existing tooling and widely used languages are a poor fit - as well as people who genuinely enjoy developing their own PLs that have their own ways of doing things. >Where does the build complexity/hiring difficulty/lack of tooling tradeoff make sense With VC money, anything is possible... >build complexity Fairly nil. Contemporary build systems are language agnostic, and the steps to make one that functions good enough are well known and can be thrown together in a week or so. Not to mention it's become increasingly common for "widely used" PLs to fallback on things like python scripts to handle builds. >hiring difficulty It's actually a fantastic way to weed people out and find good candidates. In my (limited) experience, people willing and able to learn a new language (or have a few under their belt) are generally the exact kinds of people you want to hire anyway. Code switching between languages on a daily basis is a fantastic skill, and leads to good developers and mindshare, helps create a diverse technical background. >lack of tooling This is a legit problem, and one that a lot of folks stumble on. But luckily building tooling is a great way to dogfood your language - and it's never been easier to integrate with various tool frameworks via standard protocols. But that said - every company just getting off the ground lacks tooling. For language devs it's a language server, debugger, disassembler, and what have you. For your bootstrapped startup it's build systems/procedures and code review, ERPs and CRMs, etc. Building your own tooling is a part of the growth of a business, tech or otherwise, it's just that when you work on a custom language you have to build some different tools than a SaaS might. I'll throw one more in though that's the biggest hurdle - wheel reinvention. Stuff you take for granted in any language or have great packages for are the biggest blockers to being productive. But you do the ROI math and decide if it makes sense, so hopefully your lang has good FFI. Also worth mentioning - if you're working in an esoteric language with heavy contribution by your own team, you're probably doing it because you have a lot of work that looks nothing like putting together a CRUD app or developing a backend for your latest API for your SaaS idea.

gingerBill 7y ago
Odin's `foreign` system (FFI) is very easy to use and allows for a lot simpler build system in the process too. I highly recommend you read the overview (https://odin-lang.org/docs/overview/ https://odin-lang.org/docs/overview/) and many of the Odin wrappers and bindings for more information on this topic https://github.com/odin-lang/odin-libs https://github.com/odin-lang/odin-libs