9 ms·

Seems like the wrong problem to solve. "Systems programming" is hard, and should be hard, for reasons unrelated to the programming language used. Something like

• farresito 2y ago
  I think that's what they are trying to achieve with Mojo.
  • sa-code 2y ago
    Agreed, although the language still feels like a tech demo. They don't even have a package manager yet. I'm curious and hopeful to see what it looks like in a year
    • mirekrusin 2y ago
      They don't yet have `class` support.
      • sa-code 2y ago
        They have their own version called struct which works in a very similar way. I feel like this should be mentioned when saying that `class` support didn't yet exist
        • mirekrusin 2y ago
          Yes, you're right and struct is _the_ interesting part about mojo and is enough to write interesting things in it. Floodgates will open though once class is also supported.
  • almostgotcaught 2y ago
    [flagged]
  • fuzztester 2y ago
    Posted this Chris Lattner interview about Mojo to HN yesterday. The video is just 6 days old. It's on the Developer Voices channel. https://news.ycombinator.com/item?id=40285414 https://news.ycombinator.com/item?id=40285414
• ddorian43 2y ago
  Isn't Java better than Swift/C# ? (more open, green threads, better ecosystem).
  • pjc50 2y ago
    Debateable; I much prefer the dotnet ecosystem, even if it's less open. I suspect green threads vs C# async is another matter of taste as well. Plus Oracle is a much more annoying overlord for Java.
  • alternatex 2y ago
    Someone prefers Java over Swift/C#? Now I've seen everything.
  • kryptiskt 2y ago
    C# has value types, stackalloc, simpler FFI and a rich SIMD API, offering far better control for low-level code than Java. I don't feel green threads is a system level concern, and while Java's ecosystem is huge, it's also very enterprisey. Also, I'd disagree with more open, C# is under a more permissive license and Oracle has actually been litigious over Java.
    • pjmlp 2y ago
      While I also favour C# over Java, the languages, the runtimes it is a bit different, given the wide spectrum of JVM implementations in the wild. Lets not forget that C# only exists because Sun won the lawsuit over J++, where several C# features were born (J/Direct => P/Invoke, events, JFC => Windows Forms, COM support), and Ext-VOS (the COM next generation runtime) paper refers to J++, before COOL became C#, and J# was introduced as migration path from J++. Ironically, after all these years, as means to keep Azure relevant for the Java community, Microsoft has become a OpenJDK contributor by acquiring jClarity, including ARM support on Windows, better escape analysis, and has their own distribution. And VSCode plugins for Java, developed in collaboration with Red-Hat, are much better than C# Dev Kit, without requiring a Microsoft account.
      • 2y ago
• kkukshtel 2y ago
  C# nails this consistently, it's not worth hand waving it away because it isn't FOSS. Rust drama itself suggests that a FOSS language doesn't shield it from corporate meddling.
  • raddan 2y ago
    The C# compiler has an MIT license and is available on GitHub, which is about as FOSS as it gets. https://github.com/dotnet/roslyn https://github.com/dotnet/roslyn
    • crote 2y ago
      The compiler is one thing, the ecosystem is another. Sure, you can compile and host your .NET Core web app on Linux these days, but desktop applications are a completely different beast. You're often lucky if one exists at all, and if it does there's a decent chance it's not designed for "modern" C#-on-Linux. It really isn't a viable option yet, maybe in a decade or two.
      • stanac 2y ago
        WPF is MIT licensed, available on github. The fact that it's windows only doesn't make it less FOSS. Microsoft doesn't have incentive to port it to other platforms but other people and companies are free to do that.
        • MarkSweep 2y ago
          WPF is not the best example of open source, as some components are still closed source. Though it only runs on Windows, a closed source operating system, so perhaps that is not so important. https://github.com/dotnet/wpf/issues/2554 https://github.com/dotnet/wpf/issues/2554 That said, there are cross platform, open source .NET UI frameworks out there, including one that is inspired by WPF: https://avaloniaui.net/ https://avaloniaui.net/
  • galangalalgol 2y ago
    Those are good points, but my problem with c# is that it isn't as performant in Linux. On Linux I'd suggest go as the more performant option. In any case I like both of those so much more than swift. Swift is slower even with bounds checks off. You can't turn them off in go.
• K0nserv 2y ago
  > Seems like the wrong problem to solve. "Systems programming" is hard, and should be hard, for reasons unrelated to the programming language used. Something like Rust which forces you to constantly reevaluate your design before you even press the compile button, is ideal. I was recently musing about this on Mastodon[0], commenting on a tweet that said something to the effect of "C++ isn't complex, it just doesn't lie about the complexity of reality". I think Rust is similar, and really any system language has too be. However, there's a space between lying about reality and fully reflecting reality where useful abstractions, such as Rust's lifetimes live. If you hardline the "lying about reality" framing, any abstractions on top of machine code must be ruled out. So while I see where you are coming from, I think lots of space to improve system programming, as Rust did. > What's really lacking are safe, easy, strong typed general purpose languages that can leverage AOT compilation for high performance and static analysis etc. A language with the learning curve of Python, near C performance and strong safety guarantees of Rust. There is nothing that suggests to me such a language would not be possible. Swift and C# come closest but they are warped by their respective corporate overlords. I agree about Swift fitting this mold, it's unfortunate that it has failed to gain traction outside of Apple's ecosystem. 0: https://infosec.exchange/@k0nserv/112399102914339131 https://infosec.exchange/@k0nserv/112399102914339131
  • neonsunset 2y ago
    .NET of today seems to stand out quite a bit in comparison to many other MSFT-backed projects. Especially if you look not at non-essential and possibly azure-related (a tiny part of ecosystem) tooling but rather at the "core" itself (that is, SDK, runtime and compilers) which is distributed under permissive MIT license which you can just take and do anything with. To surprise of many outside of .NET community, it has much better performance than Swift[0][1][2] and lets you match performance of C and C++ in areas that matter. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/swift-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/csharpcore-csharpaot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (better performance for short-running benchmarks sensitive to JIT) [bonus] C# AOT vs Go https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-csharpaot.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (no direct comparison but Tl;Dr: ARC and Swift defaulting to virtual dispatch that can't always be elided with WMO results in Swift having much lower (even if more consistent) performance)
• binary132 2y ago
  I mean, Go and Java have those properties, but achieve them using managed runtimes. The first thing that crossed my mind reading this comment was Nim. It’s pretty Pythonesque (but that’s kinda what I hate about it.)
  • gwd 2y ago
    I love Go, but it certainly doesn't have the safety guarantees that Rust has. You're not going to have a memory leak or use-after-free, due to the garbage collector, but you have nil pointer dereferences and data races.
    • usrnm 2y ago
      I have seen more leaks in the golang project I currently work on than in most C++ codebases I've worked with in my career. It's trivial to leak stuff in golang, and much more difficult to make sure that you don't
      • binary132 2y ago
        Ok? Is it not trivial to leak in unsafe rust? Managed memory is safety. And frankly, OOM termination is not unsafe. If you crash the host because you ate all the system resources, that’s a different thing, and Rust doesn’t fix that either.
    • pdimitar 2y ago
      And it's trivially easy to ignore an error. Also channels and WaitGroups are easy to misuse (well, that's why there's also an ErrGroup now). I'd make Golang my 100% go-to language if it got rid of several footguns. Though let's be real, that's absolutely certain to never happen, they take their backwards compatibility extremely seriously. So we'll have to keep relying on checkers and linters that alleviate some of the pains somewhat.
      • angra_mainyu 2y ago
        I'm not aware of any serious Go project without linting and tests. In fact, most projects I've worked on won't even merge a PR with ignored errors. Also, `go test -race` is a Go feature, there's nothing wrong with using it.
• melodyogonna 2y ago
  Checkout Mojo
• _kb 2y ago
  Crystal lang also plays a bit into that space. It has a fairly expressive type system, good inference, checked nil type, and very approachable syntax.
• deleted 2y ago
  [deleted]
• brazzy 2y ago
  > "Systems programming" is hard, and should be hard, for reasons unrelated to the programming language used. The question is: is it harder than it needs to be due to accidental complexity[1] in programming language design. TFA argues that there is still some accidental complexity in the design of Rust that leaves room for an "easier" language that still allows the level of control needed for a systems language. [1] https://medium.com/@sharkaroo/navigating-complexity-in-software-the-essential-vs-the-accidental-9a742accfb8b https://medium.com/@sharkaroo/navigating-complexity-in-softw...
  • dist1ll 2y ago
    There's definitely a bunch of accidental complexity in systems programming. Even in domains with extreme performance constraints, large portion of the code base could be expressed with simpler and safer semantics like MVS.
• Lutger 2y ago
  The D programming language is mostly this, or could be this, however it has several flaws. It still isn't as polished and doesn't have the ecosystem, and is sort of trying to be Rust, C# and Python at the same time which doesn't always work out that well. But when it does, it is amazing. It also has some crazy and unusually powerful metaprogramming abilities.
• armchairhacker 2y ago
  And Kotlin, and arguably Java and Scala, and possibly Dlang and Nim. There are a lot of strongly-typed general-purpose languages.
  • dartos 2y ago
    Yeah the JVM is quite fast at this point after it starts up.
    • pjmlp 2y ago
      It can even be helped to be faster with AOT/PGO, or JIT caches. And while Android ART technically isn't Java (the plaform), its mixed execution mode with hand written Assembly interpreter, JIT, AOT with PGO shared via play store is quite cool.
• angra_mainyu 2y ago
  >A language with the learning curve of Python, near C performance and strong safety guarantees of Rust. Sounds like Go or Zig, though Go is slightly less safe and slower - in turn being much easier. Though I'd reach for Go first if I'm working with anything concurrent. Concurrency is hard, and Go really helps with getting it right.
  • kaba0 2y ago
    Go is not at all playing in the same league as Zig or Rust. Of course managed languages are more than fine for almost every use case, but I really hate this trends to wash go together with low-level languages for absolutely no good reason.
    • mwcz 2y ago
      That's not just a trend. There are many areas of programming where a choice between Rust and Go is perfectly reasonable. Rust is playing on Go's turf, but Go isn't playing on Rust's, if you get my meaning.
      • pjmlp 2y ago
        F-Secure created USB Armory firmware in Go instead of Rust, exactly because they wanted to make the point of it being a possible scenario for Go, regardless of what the interwebs think about the idea. USB Armory is still being sold.
  • gliptic 2y ago
    Zig doesn't have anything like the safety guarantees of Rust.
• knighthack 2y ago
  I really must suggest Nim.
• prmph 2y ago
  What's actually needed is to start with JS, and: - Strip out the bad parts. - Add types, more functional features, a proper standard lib, and a standardized module system. - Allow compilation directly to performant machine or byte code. They can call it a different name if they want.
  • thfuran 2y ago
    Why start with JavaScript?
    • prmph 2y ago
      Why not?
      • thfuran 2y ago
        Because it seems so very far away from your goal. What is it bringing to the table that makes it the best starting point?
        • prmph 2y ago
          As a front-end interface, JS is pretty good. - It has simple, straightforward, and pleasant syntax/semantics. Except for a few tweaks here and there, there is no need to re-invent the wheel here. - It is pretty functional, all that's needed is to add everything-is-an-expression - It supports multiple paradigms (functional, imperative, OOP) - Since it has no types currently, a _modern_ type system can be feasibly added, supporting concepts like result/error instead of exceptions, maybe/option, pattern matching, etc. - It has easy-to-reason about async features - It has a huge ecosystem; it shouldn't be hard to port many high-quality packages to a similar language Now, the lower-level features are another matter entirely, but it shouldn't be too difficult to retrofit what we want, like multi-threading (maybe building on top of workers), utf-8 strings, and so on.
          • ctxcode 2y ago
• gumby 2y ago
  > What's really lacking are safe, easy, strong typed general purpose languages that can leverage AOT compilation for high performance and static analysis etc. The funny thing is that MACLISP could do this back in the early 70s. While Lisp is a dynamically typed, GCed language, MACLISP let you annotate variables to promise that they would only be called on certain primitive types, thus supporting compile-time optimizations for numeric code and not necessarily allocate memory, follow a pointer, unbox data etc. This was critical to make packages like MACSYMA run on machines with performance in the KIPS range. Although languages like Python support similar declarations or annotations, they aren't used in the same way -- if you want performance you write the module in C++ and give it a python interface.
  • pjmlp 2y ago
    Somehow it is kind of tragedy of this industry, the amount of zig-zag it does between ideas and technologies, until mainstream finally adopts concepts that were already available during its genesis to a iluminated few.
  • bsder 2y ago
    > While Lisp is a dynamically typed, GCed language, MACLISP let you annotate variables to promise that they would only be called on certain primitive types, thus supporting compile-time optimizations for numeric code and not necessarily allocate memory, follow a pointer, unbox data etc. And woe betide you if you happened to violate the preconditions of one of those annotations. That kind of programming is no better than C with "Segmentation fault. Core dumped." The problem is that "system programming" or "embedded programming" isn't one thing. There are people who want to throw around a zillion polygons at 144FPS. There are people who want max performance on x86-64 shoveling around millions of network connections. There are people who need guaranteed real time response or someone dies. There are people who need to stay asleep all the time to conserve battery and only wake up once every 5 minutes to chirp some RF. These people do not have the same needs in a language yet they almost all wind up shoveled into C.
    • ModernMech 2y ago
      > These people do not have the same needs in a language yet they almost all wind up shoveled into C. Why is that tho? There are better languages for each of those applications. What do you think, is it business requirements? Hardware? Regulation? Legacy code?
• nikhilsimha 2y ago
  Nim?
• deleted 2y ago
  [deleted]