What do people actually mean when they say "the syntax is janky"?
I often see comparisons to languages like Python and Kotlin, but both encode far less information on their syntax because they don't have the same features as Rust, so there's no way for them to express the same semantics as rust.
Sure, you can make Rust look simpler by removing information, but at that point you're not just changing syntax, you're changing the language's semantics.
Is there any language that preserves the same level of type information while using a less "janky" syntax?
I don't know if there is, but there certainly needs to be. All of Rust's syntax seems to be needed to support its semantics, but it also undeniably crosses a threshold of "too much syntax". Though I do agree with the person above who said that every language that's not Lisp has too much syntax.
The thing is, inaction is not simply "not taking an action"; Inaction is taking active action of accepting the current solution.
> I doubt that the best proposals are so horrible for some people that they’d hold a grudge and leave Go.
But people may leave go if they constantly avoid fixing any of problems with the language. The more time passes, the more unhappy people become with the language. It will be a death by a thousand cuts.
I love go. But their constant denial do fix obvious problems is tiring.
> But people may leave go if they constantly avoid fixing any of problems with the language.
For many people the current Go error handling just isn't a problem. Some even prefer it over the overengineered solutions in other languages. This brutalist simplicity is a core design feature I personally enjoy the most with Go, and forcing me to use some syntax sugar or new keywords would make it less enjoyable to use. I also don't think that generics were a net benefit, but at least I'm not forced to use them.
Go is a cemented language at this point, warts and all. People who don't like it likely won't come around if the issues they're so vocal about were fixed. It's not like there's a shortage of languages to choose from.
The devil's in the implementation details though. The operating system may provide both fully-preemptive threads on which to schedule user space cooperative threads (scheduling on system call). At that point green threads (e.g. threading implemented by a virtual machine on top of the operating system) do not provide the same value. This is actually why Green threads were effectively pulled out of Java for a few decades.
Fibers are distinct in that they have no scheduling and are code being run on a thread - if the thread is preempted, it will resume on that same thread. Unlike cooperative threading, they must explicitly yield.
Coroutines have such varying implementations that you would need to define requirements to know if they count as fibers or not - for instance, whether you mandate a C-compatible stack.
There's one thing missing here, whereas fibers are cooperative, they have a user space scheduler deciding which fiber to switch to on a thread when you yield, coroutines specify who they're yielding to.
You'll notice the function's documentation is "Schedules a fiber. The function must be called on a fiber." so while it may not be a literal difference (after all they're both semi-user space), they are difference systems to use, but they're both roughly at the same level of "power".
If you're not using a scheduler with fibers then I'd argue you shouldn't be calling it a fibers system (and rather coroutines), since otherwise it's a distinction without a difference.
It might not be a great language to create compilers, but python also has a pretty good structured pattern matching as of version 3.10:
class BinOp:
def __init__(self, left, right, operator):
self.left = left
self.right = right
self.operator = operator
sum_of_ints = BinOp(left=1, right=1, operator='+')
match sum_of_ints:
case BinOp(left=int(left), right=int(right), operator='+'):
print(f'Summing int {left} + {right}')
case BinOp(left=str(left), right=str(right), operator='+'):
print(f'Concateneting strings {left} + {right}')
case _:
print('Don\'t know how to sum this')
One shortcoming (though it's nice that Python has this) of this is that this isn't checked for exhaustiveness by the compiler (because there isn't a Python one) which makes it easy to forget cases and introduce bugs.
Not sure if there are any runtime checks for this?
I believe that every game have this problem if you are far enough away from the origin.
3kliksphilip did a great video on this subject: https://www.youtube.com/watch?v=eK7eNgiQfhk
I often see comparisons to languages like Python and Kotlin, but both encode far less information on their syntax because they don't have the same features as Rust, so there's no way for them to express the same semantics as rust.
Sure, you can make Rust look simpler by removing information, but at that point you're not just changing syntax, you're changing the language's semantics.
Is there any language that preserves the same level of type information while using a less "janky" syntax?