I'm so bored with all this reactionary tech. I don't understand the urge to reinvent everything from first principles while ignoring the last 30 years of advances in computing. I was alive back then. Things weren't actually better.
Criticizing Hare language approach for generic data structures
131–140 of 272 posts
Re: Criticizing Hare language approach for generic data structures
#132Earlier quoted context omitted.
My understanding is that Go has several features that make it unsuitable as a Linux kernel language, e.g. automatic garbage collection, its concurrency model, and possibly the nature of its runtime dependency (which is related to the previous two items.)
Garbage collection is not mandatory, and the concurrency model is often hailed as one of Gos best features.
>Garbage collection is not mandatory
What does that mean? Isn't GC a fundamental part of Go?
Re: Criticizing Hare language approach for generic data structures
#133Earlier quoted context omitted.
Easy to write, sure. But every time a developer has to look at it for the first time, they'll need to learn this hashmap's interface. Do I need to manage memory? Does it manage memory? How do I iterate? How do I add a new key space without thrashing the original implementation and making it twice as complicated? That's the biggest thing a standard interface gives you. Even if it's less performant and not well-designe…
I agree with all your points except "are actually well-designed and performant". I mean they perform well enough but when I write simple hashmaps that perform better than libstdc++ (yes with the same hash) anecdotally I don't have a lot of confidence.
Keep in mind that
- those hash maps are optimized for large sets
- they work around several edge cases
- they implement way more features than an in-house implementation
- they need to support many types of hardware
A decent engineer can beat the std collections in a day on performance. But to do that in production over a decade with shifting requirements is a different ball game.
Re: Criticizing Hare language approach for generic data structures
#134Earlier quoted context omitted.
Its not existing kernel devs that suddenly switched to rust. It is the incoming cohort.
For someone to start using a new language in the Kernel, some of the existing "guard" has to approve it, meaning they've investigated if it's fit or not. Or can anyone willy-nilly contribute to the Kernel without anyone approving changes going into the main branch?
Miguel Ojeda is doing the lion’s share of the work here, and he is a kernel maintainer: https://ojeda.dev/
The person you’re replying to is either deeply misinformed or trolling
Re: Criticizing Hare language approach for generic data structures
#135Earlier quoted context omitted.
You sure speak surely about "us" like there is just one group of programmers out there. Some people love JavaScript, some people love C. Some people only use programming languages, some create new ones. Live and let live, don't tell others what they need.
Honestly memory unsafe languages shouldn't be used with exception of very few corner cases. It's the same reason why we no longer allow cars without seatbelts. You don't go around saying that seatbelts shouldn't be mandatory because you don't need them.
What's with this obsession about what other people do? You don't have to use a memory unsafe language, but others might.
Re: Criticizing Hare language approach for generic data structures
#136Earlier quoted context omitted.
Rust absolutely benefits embedded software. A big reason is that the type system allows libraries to let you enforce invariants at compile time. For example, your i2c controller only supports two specific pins and they have to be in a specific mode? That can be a compile error if you make a mistake.
Configuring pins and peripherals with code is a chore, I use graphical tools for that. But C has no problems abstracting away peripherals, just hide the register bits in a private TU and expose i2c_init(), i2c_write(), etc.
> just hide the register bits in a private TU and expose i2c_init(), i2c_write(), etc.
That's not a zero cost abstraction, unless these "functions" are actually provided in an include file. Embedded programming is often performance sensitive, so this can matter.
Re: Criticizing Hare language approach for generic data structures
#137Earlier quoted context omitted.
Functional programming patterns are very common in Rust code. It doesn’t have automatic currying or higher-kinded types but it has generic associated types, anonymous functions, closures, and a rich set of collections with functional processing methods in the standard library.
A lot of the standard library and an extensive part of the community ecosystem lives and breathes mutation at both the edges and in the internals, something people normally would avoid when trying to stick with functional programming. Sure, some mutation is always needed, but Rust wouldn't be the first language I'd pick if I want to focus on functional programming for sure.
No, but it’s widely acknowledged that functional programming features are useful even in imperative languages. Almost every imperative language that isn’t C, Go, or Hare has them. Java, C#, JavaScript, Python, Ruby. You should take a look at all the functions available on iterators in Rust if you haven’t. The Rust community tends to prefer using iterators to express things like looping when possible, which is a more functional style.
Re: Criticizing Hare language approach for generic data structures
#138Earlier quoted context omitted.
We don’t need more memory-unsafe languages with no generics and no functional programming. We just don’t. If it were a toy project for learning and pedagogical purposes that’s one thing but for code that’s supposed to be used in production it’s useless.
What, in your opinion, does functional programming bring to the table for writing things Hare is designed for?
Same things it does for Rust.
Re: Criticizing Hare language approach for generic data structures
#139Why do people spend so much energy shooting down a language nobody uses? If you don’t like it you don’t have to use it. I would hate to be the creator of Hare and get so much crap for simply daring to exist. He is making a language he likes and wants to use. There are probably some people who like it and find it useful. Good for them! A lot of us have dreams of building our own language. He is following his passions…
If the author of Hare didn't want feedback on his language, or didn't want other people to use his language, he shouldn't have advertised it in blog posts and on sites like https://harelang.org/ , which is clearly an advertisement for the language. As it happens, he has. You might think "nobody will use the language", but if nobody pushes back and says why people shouldn't use the language, perhaps people will start…
Also early on in the language seems a great time to respond to feedback. 3 years in when it has traction is terrible, heh.
Re: Criticizing Hare language approach for generic data structures
#140Why do people spend so much energy shooting down a language nobody uses? If you don’t like it you don’t have to use it. I would hate to be the creator of Hare and get so much crap for simply daring to exist. He is making a language he likes and wants to use. There are probably some people who like it and find it useful. Good for them! A lot of us have dreams of building our own language. He is following his passions…
We don’t need more memory-unsafe languages with no generics and no functional programming. We just don’t. If it were a toy project for learning and pedagogical purposes that’s one thing but for code that’s supposed to be used in production it’s useless.
This point has been made so many times that it gets tiresome. Perhaps that's ok, but it doesn't really tell us anything new.